9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
[Docker]: https://www.docker.com/
[OCI]: https://opencontainers.org/
## 1. Quick Start
Fossil ships a `Dockerfile` at the top of its source tree,
[here](/file/Dockerfile), which you can build like so:
```
$ docker build -t fossil .
```
If the image built successfully, you can create a container from it and
test that it runs:
|
|
|
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
[Docker]: https://www.docker.com/
[OCI]: https://opencontainers.org/
## 1. Quick Start
Fossil ships a `Dockerfile` at the top of its source tree,
[here][DF], which you can build like so:
```
$ docker build -t fossil .
```
If the image built successfully, you can create a container from it and
test that it runs:
|
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
Contrast the raw “`docker`” commands above, which create an
_unversioned_ image called `fossil:latest` and from that a container
simply called `fossil`. The unversioned names are more convenient for
interactive use, while the versioned ones are good for CI/CD type
applications since they avoid a conflict with past versions; it lets you
keep old containers around for quick roll-backs while replacing them
with fresh ones.
## 2. <a id="storage"></a>Repository Storage Options
If you want the container to serve an existing repository, there are at
least two right ways to do it.
|
>
>
|
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
Contrast the raw “`docker`” commands above, which create an
_unversioned_ image called `fossil:latest` and from that a container
simply called `fossil`. The unversioned names are more convenient for
interactive use, while the versioned ones are good for CI/CD type
applications since they avoid a conflict with past versions; it lets you
keep old containers around for quick roll-backs while replacing them
with fresh ones.
[DF]: /file/Dockerfile
## 2. <a id="storage"></a>Repository Storage Options
If you want the container to serve an existing repository, there are at
least two right ways to do it.
|
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
|
We’ll assume your Fossil repository stores something called
“`myproject`” within `~/museum/myproject/repo.fossil`, named according
to the reasons given [above](#repo-inside). We’ll make consistent use of
this naming scheme in the examples below so that you will be able to
replace the “`myproject`” element of the various file and path names.
If you use [the stock `Dockerfile`](/file/dockerfile) to generate your
base image, `nspawn` won’t recognize it as containing an OS unless you
put a line like this into the first stage:
```
COPY containers/os-release /etc/os-release
```
That will let you produce a `systemd` “machine” via the OCI image:
```
$ make container
$ docker container export $(make container-version) |
|
|
|
|
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
|
We’ll assume your Fossil repository stores something called
“`myproject`” within `~/museum/myproject/repo.fossil`, named according
to the reasons given [above](#repo-inside). We’ll make consistent use of
this naming scheme in the examples below so that you will be able to
replace the “`myproject`” element of the various file and path names.
If you use [the stock `Dockerfile`][DF] to generate your
base image, `nspawn` won’t recognize it as containing an OS unless you
put a line like this into the first stage:
```
COPY containers/os-release /etc/os-release
```
That will let you produce a `systemd` “machine” via the OCI image:
```
$ make container
$ docker container export $(make container-version) |
|