Merge pull request #905 from infosiftr/multiarch

Initial basic multiarch support
This commit is contained in:
yosifkit 2017-05-12 12:11:39 -07:00 committed by GitHub
commit 0c308c26c1
17 changed files with 119 additions and 83 deletions

View File

@ -1,13 +1,18 @@
#!/bin/bash
set -e
set -Eeuo pipefail
repo="$1"
repo="${1:-}"
if [ -z "$repo" ]; then
echo >&2 "usage: $0 repo"
echo >&2 " ie: $0 hylang"
exit 1
fi
# if we haven't set BASHBREW_LIBRARY explicitly (like Jenkins does, for example), don't trust the local library
if [ -z "${BASHBREW_LIBRARY:-}" ]; then
repo="https://github.com/docker-library/official-images/raw/master/library/$repo"
fi
bashbrew cat \
-F "$(dirname "$BASH_SOURCE")/$(basename "$BASH_SOURCE" .sh).tmpl" \
"https://github.com/docker-library/official-images/raw/master/library/$repo"
"$repo"

View File

@ -1,4 +1,4 @@
## `%%REPO%%:alpine`
## `%%IMAGE%%:alpine`
This image is based on the popular [Alpine Linux project](http://alpinelinux.org), available in [the `alpine` official image](https://hub.docker.com/_/alpine). Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

View File

@ -1,7 +1,7 @@
# Image Variants
The `%%REPO%%` images come in many flavors, each designed for a specific use case.
The `%%IMAGE%%` images come in many flavors, each designed for a specific use case.
## `%%REPO%%:<version>`
## `%%IMAGE%%:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

View File

@ -1,6 +1,6 @@
## `%%REPO%%:onbuild`
## `%%IMAGE%%:onbuild`
This image makes building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%REPO%%:onbuild` will be enough to create a stand-alone image for your project.
This image makes building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%IMAGE%%:onbuild` will be enough to create a stand-alone image for your project.
While the `onbuild` variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over *when* the `ONBUILD` triggers fire (see also [`docker/docker#5714`](https://github.com/docker/docker/issues/5714), [`docker/docker#8240`](https://github.com/docker/docker/issues/8240), [`docker/docker#11917`](https://github.com/docker/docker/issues/11917)).

View File

@ -1,3 +1,3 @@
## `%%REPO%%:slim`
## `%%IMAGE%%:slim`
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `%%REPO%%`. Unless you are working in an environment where *only* the %%REPO%% image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `%%IMAGE%%`. Unless you are working in an environment where *only* the `%%IMAGE%%` image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

View File

@ -1,4 +1,4 @@
## `%%REPO%%:windowsservercore`
## `%%IMAGE%%:windowsservercore`
This image is based on [Windows Server Core (`microsoft/windowsservercore`)](https://hub.docker.com/r/microsoft/windowsservercore/). As such, it only works in places which that image does, such as Windows 10 Professional/Enterprise (Anniversary Edition) or Windows Server 2016.

View File

@ -1,7 +1,7 @@
# Image Variants
The `%%REPO%%` images come in many flavors, each designed for a specific use case.
The `%%IMAGE%%` images come in many flavors, each designed for a specific use case.
## `%%REPO%%:<version>`
## `%%IMAGE%%:<version>`
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

View File

@ -10,10 +10,14 @@ fi
dir="$(dirname "$(readlink -f "$BASH_SOURCE")")"
repoDir="$dir/../$repo"
url='https://raw.githubusercontent.com/docker-library/official-images/master/library/'"$repo"
# if we haven't set BASHBREW_LIBRARY explicitly (like Jenkins does, for example), don't trust the local library
if [ -z "${BASHBREW_LIBRARY:-}" ]; then
repo="https://github.com/docker-library/official-images/raw/master/library/$repo"
fi
IFS=$'\n'
tags=( $(bashbrew cat -f '{{ range .Entries }}{{ join "\n" .Tags }}{{ "\n" }}{{ end }}' "$url") )
tags=( $(bashbrew cat -f '{{ range .Entries }}{{ join "\n" .Tags }}{{ "\n" }}{{ end }}' "$repo") )
unset IFS
text=
@ -29,7 +33,7 @@ for tag in "${tags[@]}"; do
done
if [ "$text" ]; then
baseImage="$(bashbrew cat -f '{{ .DockerFrom .TagEntry }}' "$url":latest)"
baseImage="$(bashbrew cat -f '{{ .DockerFrom .TagEntry }}' "$repo":latest)"
baseImage="${baseImage%:*}"
echo

View File

@ -13,7 +13,7 @@ BusyBox combines tiny versions of many common UNIX utilities into a single small
## Run BusyBox shell
```console
$ docker run -it --rm busybox
$ docker run -it --rm %%IMAGE%%
```
This will drop you into an `sh` shell to allow you to do what you want inside a BusyBox system.
@ -21,19 +21,9 @@ This will drop you into an `sh` shell to allow you to do what you want inside a
## Create a `Dockerfile` for a binary
```dockerfile
FROM busybox
FROM %%IMAGE%%
COPY ./my-static-binary /my-static-binary
CMD ["/my-static-binary"]
```
This `Dockerfile` will allow you to create a minimal image for your statically compiled binary. You will have to compile the binary in some other place like another container. For a simpler alternative that's similarly tiny but easier to extend, [see `alpine`](https://hub.docker.com/_/alpine/).
## Image Variants
This image contains BusyBox built against various "libc" variants (for a comparison of "libc" variants, [Eta Labs has a very nice chart](http://www.etalabs.net/compare_libcs.html) which lists many similarities and differences).
- `busybox:glibc`: [glibc from Debian](https://packages.debian.org/jessie/libc6) (which is then included in the image)
- `busybox:musl`: [musl from Alpine](https://pkgs.alpinelinux.org/package/main/x86_64/musl) (statically compiled)
- `busybox:uclibc`: [uClibc](https://uclibc.org) via [Buildroot](https://buildroot.org) (statically compiled)
For more information about the specific particulars of the build process for each variant, see `Dockerfile.builder` in the same directory as each variant's `Dockerfile` (see links above).

3
busybox/variant-glibc.md Normal file
View File

@ -0,0 +1,3 @@
## `%%IMAGE%%:glibc`
- [glibc from Debian](https://packages.debian.org/search?searchon=names&exact=1&suite=all&section=all&keywords=libc6) (which is then included in the image)

3
busybox/variant-musl.md Normal file
View File

@ -0,0 +1,3 @@
## `%%IMAGE%%:musl`
- [musl from Alpine](https://pkgs.alpinelinux.org/packages?name=musl) (statically compiled)

View File

@ -0,0 +1,3 @@
## `%%IMAGE%%:uclibc`
- [uClibc](https://uclibc.org) via [Buildroot](https://buildroot.org) (statically compiled)

5
busybox/variant.md Normal file
View File

@ -0,0 +1,5 @@
# Image Variants
The `%%IMAGE%%` images contain BusyBox built against various "libc" variants (for a comparison of "libc" variants, [Eta Labs has a very nice chart](http://www.etalabs.net/compare_libcs.html) which lists many similarities and differences).
For more information about the specific particulars of the build process for each variant, see `Dockerfile.builder` in the same directory as each variant's `Dockerfile` (see links above).

View File

@ -14,12 +14,12 @@ Please refer to [upstream's excellent (and comprehensive) documentation](https:/
It is also worth checking out the [`examples/` directory from upstream](http://www.haproxy.org/git?p=haproxy-1.7.git;a=tree;f=examples).
Note: Many configuration examples propose to put `daemon` into the `global` section to run haproxy as daemon. Do **not** configure this or the Docker container will exit immediately after launching because the haproxy process would go into the background.
Note: Many configuration examples propose to put `daemon` into the `global` section to run HAProxy as daemon. Do **not** configure this or the Docker container will exit immediately after launching because the HAProxy process would go into the background.
## Create a `Dockerfile`
```dockerfile
FROM haproxy:1.7
FROM %%IMAGE%%:1.7
COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg
```
@ -41,22 +41,22 @@ $ docker run -it --rm --name haproxy-syntax-check my-haproxy haproxy -c -f /usr/
$ docker run -d --name my-running-haproxy my-haproxy
```
You may need to publish the ports your haproxy is listening on to the host by specifying the -p option, for example -p 8080:80 to publish port 8080 from the container host to port 80 in the container. Make sure the port you're using is free.
You may need to publish the ports your HAProxy is listening on to the host by specifying the -p option, for example -p 8080:80 to publish port 8080 from the container host to port 80 in the container. Make sure the port you're using is free.
## Directly via bind mount
```console
$ docker run -d --name my-running-haproxy -v /path/to/etc/haproxy:/usr/local/etc/haproxy:ro haproxy:1.7
$ docker run -d --name my-running-haproxy -v /path/to/etc/haproxy:/usr/local/etc/haproxy:ro %%IMAGE%%:1.7
```
Note that your host's `/path/to/etc/haproxy` folder should be populated with a file named `haproxy.cfg`. If this configuration file refers to any other files within that folder then you should ensure that they also exist (e.g. template files such as `400.http`, `404.http`, and so forth). However, many minimal configurations do not require any supporting files.
### Reloading config
If you used a bind mount for the config and have edited your `haproxy.cfg` file, you can use haproxy's graceful reload feature by sending a `SIGHUP` to the container:
If you used a bind mount for the config and have edited your `haproxy.cfg` file, you can use HAProxy's graceful reload feature by sending a `SIGHUP` to the container:
```console
$ docker kill -s HUP my-running-haproxy
```
The entrypoint script in the image checks for running the command `haproxy` and replaces it with `haproxy-systemd-wrapper` from haproxy upstream which takes care of signal handling to do the graceful reload. Under the hood this uses the `-sf` option of haproxy so "there are two small windows of a few milliseconds each where it is possible that a few connection failures will be noticed during high loads" (see [Stopping and restarting HAProxy](http://www.haproxy.org/download/1.7/doc/management.txt)).
The entrypoint script in the image checks for running the command `haproxy` and replaces it with `haproxy-systemd-wrapper` from HAProxy upstream which takes care of signal handling to do the graceful reload. Under the hood this uses the `-sf` option of `haproxy` so "there are two small windows of a few milliseconds each where it is possible that a few connection failures will be noticed during high loads" (see [Stopping and restarting HAProxy](http://www.haproxy.org/download/1.7/doc/management.txt)).

View File

@ -11,19 +11,33 @@ Python is an interpreted, interactive, object-oriented, open-source programming
## Create a `Dockerfile` in your Python app project
```dockerfile
FROM python:3-onbuild
FROM %%IMAGE%%:3
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD [ "python", "./your-daemon-or-script.py" ]
```
or (if you need to use Python 2):
```dockerfile
FROM python:2-onbuild
FROM %%IMAGE%%:2
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD [ "python", "./your-daemon-or-script.py" ]
```
These images include multiple `ONBUILD` triggers, which should be all you need to bootstrap most applications. The build will `COPY` a `requirements.txt` file, `RUN pip install` on said file, and then copy the current directory into `/usr/src/app`.
You can then build and run the Docker image:
```console
@ -36,11 +50,11 @@ $ docker run -it --rm --name my-running-app my-python-app
For many simple, single file projects, you may find it inconvenient to write a complete `Dockerfile`. In such cases, you can run a Python script by using the Python Docker image directly:
```console
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp python:3 python your-daemon-or-script.py
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp %%IMAGE%%:3 python your-daemon-or-script.py
```
or (again, if you need to use Python 2):
```console
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp python:2 python your-daemon-or-script.py
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp %%IMAGE%%:2 python your-daemon-or-script.py
```

View File

@ -1,6 +1,6 @@
## `%%REPO%%:onbuild`
## `%%IMAGE%%:onbuild`
This image feeds your `requirements.txt` file automatically to `pip` in order to make building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%REPO%%:onbuild` will be enough to create a stand-alone image for your project.
This image feeds your `requirements.txt` file automatically to `pip` in order to make building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%IMAGE%%:onbuild` will be enough to create a stand-alone image for your project.
While the `onbuild` variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over *when* the `ONBUILD` triggers fire (see also [`docker/docker#5714`](https://github.com/docker/docker/issues/5714), [`docker/docker#8240`](https://github.com/docker/docker/issues/8240), [`docker/docker#11917`](https://github.com/docker/docker/issues/11917)).

View File

@ -1,42 +1,46 @@
#!/bin/bash
set -eo pipefail
set -Eeuo pipefail
cd "$(dirname "$(readlink -f "$BASH_SOURCE")")"
helperDir='.template-helpers'
repos=( "$@" )
if [ ${#repos[@]} -eq 0 ]; then
repos=( */ )
images=( "$@" )
if [ ${#images[@]} -eq 0 ]; then
images=( */ )
fi
repos=( "${repos[@]%/}" )
images=( "${images[@]%/}" )
replace_field() {
repo="$1"
targetFile="$1"
field="$2"
content="$3"
extraSed="${4:-}"
sed_escaped_value="$(echo "$content" | sed 's/[\/&]/\\&/g')"
sed_escaped_value="${sed_escaped_value//$'\n'/\\n}"
sed -ri "s/${extraSed}%%${field}%%${extraSed}/$sed_escaped_value/g" "$repo/README.md"
sed -ri -e "s/${extraSed}%%${field}%%${extraSed}/$sed_escaped_value/g" "$targetFile"
}
for repo in "${repos[@]}"; do
for image in "${images[@]}"; do
repo="${image##*/}"
namespace="${image%$repo}"
namespace="${namespace%/}"
if [ -x "$repo/update.sh" ]; then
( set -x; "$repo/update.sh" )
fi
if [ -e "$repo/content.md" ]; then
githubRepo="$(cat "$repo/github-repo")"
maintainer="$(cat "$repo/maintainer.md")"
issues="$(cat "$repo/issues.md" 2>/dev/null || cat "$helperDir/issues.md")"
getHelp="$(cat "$repo/get-help.md" 2>/dev/null || cat "$helperDir/get-help.md")"
license="$(cat "$repo/license.md" 2>/dev/null || true)"
if [ "$license" ]; then
license=$'\n\n''# License'$'\n\n'"$license"
fi
logo=
logoFile=
for f in png svg; do
@ -54,67 +58,72 @@ for repo in "${repos[@]}"; do
logo="![logo](https://raw.githubusercontent.com/docker-library/docs/$logoCommit/$logoFile)"
fi
fi
compose=
composeYml=
if [ -f "$repo/docker-compose.yml" ]; then
compose="$(cat "$repo/compose.md" 2>/dev/null || cat "$helperDir/compose.md")"
composeYml=$'```yaml\n'"$(cat "$repo/docker-compose.yml")"$'\n```'
fi
deprecated=
if [ -f "$repo/deprecated.md" ]; then
deprecated=$'# **DEPRECATED**\n\n'
deprecated+="$(cat "$repo/deprecated.md")"
deprecated+=$'\n\n'
fi
targetFile="$repo/README.md"
{
cat "$helperDir/autogenerated-warning.md"
echo
echo -n "$deprecated"
cat "$helperDir/template.md"
} > "$repo/README.md"
} > "$targetFile"
echo ' TAGS => generate-dockerfile-links-partial.sh "'"$repo"'"'
partial="$("$helperDir/generate-dockerfile-links-partial.sh" "$repo")"
[ "$partial" ]
replace_field "$repo" 'TAGS' "$partial"
replace_field "$targetFile" 'TAGS' "$partial"
echo ' CONTENT => '"$repo"'/content.md'
replace_field "$repo" 'CONTENT' "$(cat "$repo/content.md")"
replace_field "$targetFile" 'CONTENT' "$(cat "$repo/content.md")"
echo ' VARIANT => variant.sh'
replace_field "$repo" 'VARIANT' "$("$helperDir/variant.sh" "$repo")"
replace_field "$targetFile" 'VARIANT' "$("$helperDir/variant.sh" "$repo")"
# has to be after CONTENT because it's contained in content.md
echo " LOGO => $logo"
replace_field "$repo" 'LOGO' "$logo" '\s*'
replace_field "$targetFile" 'LOGO' "$logo" '\s*'
echo ' COMPOSE => '"$repo"'/compose.md'
replace_field "$repo" 'COMPOSE' "$compose"
replace_field "$targetFile" 'COMPOSE' "$compose"
echo ' COMPOSE-YML => '"$repo"'/docker-compose.yml'
replace_field "$repo" 'COMPOSE-YML' "$composeYml"
replace_field "$targetFile" 'COMPOSE-YML' "$composeYml"
echo ' LICENSE => '"$repo"'/license.md'
replace_field "$repo" 'LICENSE' "$license"
replace_field "$targetFile" 'LICENSE' "$license"
echo ' ISSUES => "'"$issues"'"'
replace_field "$repo" 'ISSUES' "$issues"
replace_field "$targetFile" 'ISSUES' "$issues"
echo ' GET-HELP => "'"$getHelp"'"'
replace_field "$repo" 'GET-HELP' "$getHelp"
replace_field "$targetFile" 'GET-HELP' "$getHelp"
echo ' MAINTAINER => "'"$maintainer"'"'
replace_field "$repo" 'MAINTAINER' "$maintainer"
replace_field "$targetFile" 'MAINTAINER' "$maintainer"
echo ' IMAGE => "'"$image"'"'
replace_field "$targetFile" 'IMAGE' "$image"
echo ' REPO => "'"$repo"'"'
replace_field "$repo" 'REPO' "$repo"
replace_field "$targetFile" 'REPO' "$repo"
echo ' GITHUB-REPO => "'"$githubRepo"'"'
replace_field "$repo" 'GITHUB-REPO' "$githubRepo"
replace_field "$targetFile" 'GITHUB-REPO' "$githubRepo"
echo
else
echo >&2 "skipping $repo: missing repo/content.md"