doc: Update overview a bit
Link to docker, note in introductory paragraph the goal of package composition on a server.
This commit is contained in:
parent
fbd97b2ef2
commit
39e4c7c6fe
|
|
@ -8,19 +8,27 @@
|
||||||
<chapter id="ostree-intro">
|
<chapter id="ostree-intro">
|
||||||
<title>Introduction</title>
|
<title>Introduction</title>
|
||||||
<para>
|
<para>
|
||||||
OSTree is best summarized in a single sentence as "git for
|
OSTree an upgrade system for Linux-based operating systems that
|
||||||
operating system binaries". At its core architecture is a
|
performs atomic upgrades of complete filesystem trees. It is
|
||||||
userspace content-addressed filesystem, and layered on top of
|
not a package system; rather, it is intended to complement them.
|
||||||
that is an administrative layer that is designed to atomically
|
A primary model is composing packages on a server, and then
|
||||||
parallel install multiple bootable Unix-like operating systems.
|
replicating them to clients.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
While it takes over some of the roles of tradtional "package
|
The underlying architecture might be summarized as "git for
|
||||||
managers" like dpkg and rpm, it is <emphasis>not</emphasis> a
|
operating system binaries". It operates in userspace, and will
|
||||||
package system; nor is it a tool for managing full disk
|
work on top of any Linux filesystem. At its core is a git-like
|
||||||
images. Instead, OSTree sits between those levels, offering a
|
content-addressed object store, and layered on top of that is
|
||||||
blend of the advantages (and disadvantages) of both.
|
bootloader configuration, management of
|
||||||
|
<filename>/etc</filename>, and other functions to perform an
|
||||||
|
upgrade beyond just replicating files.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
You can use OSTree standalone in the pure replication model,
|
||||||
|
but another approach is to add a package manager on top,
|
||||||
|
thus creating a hybrid tree/package system.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
@ -35,6 +43,7 @@
|
||||||
attached, and these are dynamically assembled on the client
|
attached, and these are dynamically assembled on the client
|
||||||
machine, after a process of dependency resolution.
|
machine, after a process of dependency resolution.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In contrast, OSTree only supports recording and deploying
|
In contrast, OSTree only supports recording and deploying
|
||||||
<emphasis>complete</emphasis> (bootable) filesystem trees. It
|
<emphasis>complete</emphasis> (bootable) filesystem trees. It
|
||||||
|
|
@ -48,24 +57,27 @@
|
||||||
included in your tree, so you should support the equivalent of
|
included in your tree, so you should support the equivalent of
|
||||||
<command>rpm -q</command> or <command>dpkg -L</command>.
|
<command>rpm -q</command> or <command>dpkg -L</command>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The OSTree core emphasizes replicating read-only OS trees via
|
The OSTree core emphasizes replicating read-only OS trees via
|
||||||
HTTP, and where the OS includes (if desired) an entirely
|
HTTP, and where the OS includes (if desired) an entirely
|
||||||
separate mechanism to install applications, stored in <filename
|
separate mechanism to install applications, stored in <filename
|
||||||
class='directory'>/var</filename> if they're system global, or
|
class='directory'>/var</filename> if they're system global, or
|
||||||
<filename class='directory'>/home</filename> for per-user
|
<filename class='directory'>/home</filename> for per-user
|
||||||
application installation.
|
application installation. An example application mechanism is
|
||||||
|
<ulink url="http://docker.io/">Docker</ulink>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
However, it is entirely possible to use OSTree underneath a
|
However, it is entirely possible to use OSTree underneath a
|
||||||
package system, where the contents of <filename
|
package system, where the contents of <filename
|
||||||
class='directory'>/usr</filename> are computed on the client.
|
class='directory'>/usr</filename> are computed on the client.
|
||||||
For example, when installing a package, rather than mutating the
|
For example, when installing a package, rather than changing the
|
||||||
currently running filesystem, the package manager could assemble
|
currently running filesystem, the package manager could assemble
|
||||||
a new filesystem tree that includes the new package, record it
|
a new filesystem tree that layers the new packages on top of a
|
||||||
in the local OSTree repository, and then set it up for the next
|
base tree, record it in the local OSTree repository, and then
|
||||||
boot. To support this model, OSTree provides an
|
set it up for the next boot. To support this model, OSTree
|
||||||
(introspectable) C shared library.
|
provides an (introspectable) C shared library.
|
||||||
</para>
|
</para>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue