github.com/Heebron/moby@v0.0.0-20221111184709-6eab4f55faf7/project/PACKAGERS.md (about) 1 # Dear Packager, 2 3 If you are looking to make Docker available on your favorite software 4 distribution, this document is for you. It summarizes the requirements for 5 building and running the Docker client and the Docker daemon. 6 7 ## Package Name 8 9 If possible, your package should be called "docker". If that name is already 10 taken, a second choice is "docker-engine". Another possible choice is "docker.io". 11 12 ## Official Build vs Distro Build 13 14 The Docker project maintains its own build and release toolchain. It is pretty 15 neat and entirely based on Docker (surprise!). This toolchain is the canonical 16 way to build Docker. We encourage you to give it a try, and if the circumstances 17 allow you to use it, we recommend that you do. 18 19 You might not be able to use the official build toolchain - usually because your 20 distribution has a toolchain and packaging policy of its own. We get it! Your 21 house, your rules. The rest of this document should give you the information you 22 need to package Docker your way, without denaturing it in the process. 23 24 ## Build Dependencies 25 26 The Dockerfile contains the most up-to-date list of build-time dependencies. 27 28 ### Go Dependencies 29 30 All Go dependencies are vendored under "./vendor". They are used by the official 31 build, so the source of truth for the current version of each dependency is 32 whatever is in "./vendor". 33 34 If you would rather (or must, due to distro policy) package these dependencies 35 yourself, take a look at "vendor.mod" for an easy-to-parse list of the 36 exact version for each. 37 38 ## Stripping Binaries 39 40 Please, please, please do not strip any compiled binaries. This is really 41 important. 42 43 In our own testing, stripping the resulting binaries sometimes results in a 44 binary that appears to work, but more often causes random panics, segfaults, and 45 other issues. Even if the binary appears to work, please don't strip. 46 47 See the following quotes from Dave Cheney, which explain this position better 48 from the upstream Golang perspective. 49 50 ### [go issue #5855, comment #3](https://code.google.com/p/go/issues/detail?id=5855#c3) 51 52 > Super super important: Do not strip go binaries or archives. It isn't tested, 53 > often breaks, and doesn't work. 54 55 ### [launchpad golang issue #1200255, comment #8](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/8) 56 57 > To quote myself: "Please do not strip Go binaries, it is not supported, not 58 > tested, is often broken, and doesn't do what you want" 59 > 60 > To unpack that a bit 61 > 62 > * not supported, as in, we don't support it, and recommend against it when 63 > asked 64 > * not tested, we don't test stripped binaries as part of the build CI process 65 > * is often broken, stripping a go binary will produce anywhere from no, to 66 > subtle, to outright execution failure, see above 67 68 ### [launchpad golang issue #1200255, comment #13](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/13) 69 70 > To clarify my previous statements. 71 > 72 > * I do not disagree with the debian policy, it is there for a good reason 73 > * Having said that, it stripping Go binaries doesn't work, and nobody is 74 > looking at making it work, so there is that. 75 > 76 > Thanks for patching the build formula. 77 78 ## Building Docker 79 80 Please use our build script ("./hack/make.sh") for compilation. 81 82 ### `DOCKER_BUILDTAGS` 83 84 There are build tags for disabling graphdrivers, if necessary. By default, 85 support for all graphdrivers are built in. 86 87 To disable btrfs: 88 ```bash 89 export DOCKER_BUILDTAGS='exclude_graphdriver_btrfs' 90 ``` 91 92 To disable devicemapper: 93 ```bash 94 export DOCKER_BUILDTAGS='exclude_graphdriver_devicemapper' 95 ``` 96 97 To disable aufs: 98 ```bash 99 export DOCKER_BUILDTAGS='exclude_graphdriver_aufs' 100 ``` 101 102 NOTE: if you need to set more than one build tag, space separate them: 103 ```bash 104 export DOCKER_BUILDTAGS='exclude_graphdriver_aufs exclude_graphdriver_btrfs' 105 ``` 106 107 ## System Dependencies 108 109 ### Runtime Dependencies 110 111 To function properly, the Docker daemon needs the following software to be 112 installed and available at runtime: 113 114 * iptables version 1.4 or later 115 * procps (or similar provider of a "ps" executable) 116 * e2fsprogs version 1.4.12 or later (in use: mkfs.ext4, tune2fs) 117 * xfsprogs (in use: mkfs.xfs) 118 * XZ Utils version 4.9 or later 119 * pigz (optional) 120 121 Additionally, the Docker client needs the following software to be installed and 122 available at runtime: 123 124 * Git version 1.7 or later 125 126 ### Kernel Requirements 127 128 The Docker daemon has very specific kernel requirements. Most pre-packaged 129 kernels already include the necessary options enabled. If you are building your 130 own kernel, you should check out `contrib/check-config.sh`. 131 132 Note that in client mode, there are no specific kernel requirements, and that 133 the client will even run on alternative platforms such as Mac OS X / Darwin. 134 135 ### Optional Dependencies 136 137 Some of Docker's features are activated by using optional command-line flags or 138 by having support for them in the kernel or userspace. A few examples include: 139 140 * AUFS graph driver (requires AUFS patches/support enabled in the kernel, and at 141 least the "auplink" utility from aufs-tools) 142 * BTRFS graph driver (requires BTRFS support enabled in the kernel) 143 * ZFS graph driver (requires userspace zfs-utils and a corresponding kernel module) 144 * Libseccomp to allow running seccomp profiles with containers 145 146 ## Daemon Init Script 147 148 Docker expects to run as a daemon at machine startup. Your package will need to 149 include a script for your distro's process supervisor of choice. Be sure to 150 check out the "contrib/init" folder in case a suitable init script already 151 exists. 152 153 In general, Docker should be run as root, similar to the following: 154 155 ```bash 156 dockerd 157 ``` 158 159 Generally, it is encouraged that additional configuration be placed in 160 `/etc/docker/daemon.json`.