Permalink
Nov 7, 2014
Jul 2, 2016
Nov 7, 2014
Jul 2, 2016
Nov 7, 2014
Jul 2, 2016
Nov 7, 2014
Jul 2, 2016
Sep 25, 2017
Sep 25, 2017
Nov 17, 2017
Sep 25, 2017
Sep 28, 2017
Jun 20, 2017
Jun 20, 2017
Jul 25, 2018
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Jun 20, 2017
Newer
100644
131 lines (93 sloc)
5.81 KB
1
# Docker Deploy
3
Installing docker is a prerequisite. The instructions differ depending on the
4
environment. Docker is comprised of two parts: the daemon server which runs on
5
Linux and accepts commands, and the client which is a Go program capable of
6
running on MacOS, all Unix variants and Windows.
7
8
## Docker Installation
9
10
Follow the [Docker install
11
instructions](https://docs.docker.com/engine/installation/).
12
13
## Available images
14
15
There are development and deploy images available.
16
17
### Development
18
19
The development image is a bulky image containing a complete build toolchain.
20
It is well suited to hacking around and running the tests (including the
21
acceptance tests). To fetch this image, run `./builder.sh pull`. The image can
22
be run conveniently via `./builder.sh`.
23
24
### Deployment
27
running CockroachDB. It is based on Debian Jessie and contains only the main
28
CockroachDB binary. To fetch this image, run `docker pull
29
cockroachdb/cockroach` in the usual fashion.
30
31
To build the image yourself, use the Dockerfile in the `deploy` directory after
32
building a release version of the binary with the development image described in
33
the previous section. The CockroachDB binary will be built inside of that
34
development container, then placed into the minimal deployment container. The
36
usual fashion. To be more specific, the steps to do this are:
37
38
```
39
go/src/github.com/cockroachdb/cockroach $ ./build/builder.sh make build TYPE=release-linux-gnu
40
go/src/github.com/cockroachdb/cockroach $ cp ./cockroach-linux-2.6.32-gnu-amd64 build/deploy/cockroach
41
go/src/github.com/cockroachdb/cockroach $ cd build/deploy && docker build -t cockroachdb/cockroach .
42
```
44
# Upgrading / extending the Docker image
45
46
Process:
47
48
- edit `build/Dockerfile` as desired
49
- run `build/builder.sh init` to test -- this will build the image locally. Beware this can take a lot of time. The result of `init` is a docker image version which you can subsequently stick into the `version` variable inside the `builder.sh` script for testing locally.
50
- Once you are happy with the result, run `build/builder.sh push` which pushes your image towards Docker hub, so that it becomes available to others. The result is again a version number, which you then *must* copy back into `builder.sh`. Then commit the change to both Dockerfile and `builder.sh` and submit a PR.
51
54
A snapshot of CockroachDB's dependencies is maintained at
55
https://github.com/cockroachdb/vendored and checked out as a submodule at
56
`./vendor`.
60
This snapshot was built and is managed using `dep` and we manage `vendor` as a
61
submodule.
63
Use the version of `dep` in `.bin` (may need to `make` first): import your new
64
dependency from the Go source you're working on, then run `.bin/dep ensure`.
68
To keep the bloat of all the changes in all our dependencies out of our main
69
repository, we embed `vendor` as a git submodule, storing its content and
70
history in [`vendored`](https://github.com/cockroachdb/vendored) instead.
72
This split across two repositories however means that changes involving
73
changed dependencies require a two step process.
74
75
- After using dep to add or update dependencies and making related code
76
changes, `git status` in `cockroachdb/cockroach` checkout will report that the
77
`vendor` submodule has `modified/untracked content`.
78
79
- Switch into `vendor` and commit all changes (or use `git -C vendor`), on a
80
new named branch.
81
82
+ At this point the `git status` in your `cockroachdb/cockroach` checkout
83
will report `new commits` for `vendor` instead of `modified content`.
86
87
- Before this commit can be submitted in a pull request to
88
`cockroachdb/cockroach`, the submodule commit it references must be available
89
on `github.com/cockroachdb/vendored`.
90
92
93
* Non-members should fork the `vendored` repo and submit a pull request to
94
`cockroachdb/vendored`, and need wait for it to merge before they will be able
95
to use it in a `cockroachdb/cockroach` PR.
99
Since the `cockroachdb/cockroach` submodule references individual commit
100
hashes in `vendored`, there is little significance to the `master` branch in
101
`vendored` -- as outlined above, new commits are always authored with the
102
previously referenced commit as their parent, regardless of what `master`
105
That said, it is critical that any ref in `vendored` that is referenced from
106
`cockroachdb/cockroach` remain available in `vendored` in perpetuity: after a
107
PR referencing a ref merges, the `vendored` `master` branch should be updated
108
to point to it before the named feature branch can be deleted, to ensure the
109
ref remains reachable and thus is never garbage collected.
113
The canonical linearization of history is always the main repo. In the event
114
of concurrent changes to `vendor`, the first should cause the second to see a
115
conflict on the `vendor` submodule pointer. When resolving that conflict, it
116
is important to re-run dep against the fetched, updated `vendor` ref, thus
117
generating a new commit in the submodule that has as its parent the one from
118
the earlier change.
122
We only want the vendor directory used by builds when it is explicitly checked
123
out *and managed* as a submodule at `./vendor`.
125
If a go build fails to find a dependency in `./vendor`, it will continue
126
searching anything named "vendor" in parent directories. Thus the vendor
127
repository is _not_ named "vendor", to minimize the risk of it ending up
128
somewhere in `GOPATH` with the name `vendor` (e.g. if it is manually cloned),
129
where it could end up being unintentionally used by builds and causing
130
confusion.