Merge pull request #905 from infosiftr/multiarch
Initial basic multiarch support
This commit is contained in:
yosifkit
GitHub
commit
0c308c26c1
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)).
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
## `%%IMAGE%%:glibc`
|
||||
|
||||
- [glibc from Debian](https://packages.debian.org/search?searchon=names&exact=1&suite=all§ion=all&keywords=libc6) (which is then included in the image)
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
## `%%IMAGE%%:musl`
|
||||
|
||||
- [musl from Alpine](https://pkgs.alpinelinux.org/packages?name=musl) (statically compiled)
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
## `%%IMAGE%%:uclibc`
|
||||
|
||||
- [uClibc](https://uclibc.org) via [Buildroot](https://buildroot.org) (statically compiled)
|
||||
|
|
@ -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).
|
||||
|
|
@ -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)).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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)).
|
||||
|
||||
|
|
|
|||
51
update.sh
51
update.sh
|
|
@ -1,26 +1,30 @@
|
|||
#!/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
|
||||
|
|
@ -69,51 +73,56 @@ for repo in "${repos[@]}"; do
|
|||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue