diff --git a/django/README.md b/django/README.md index c6223bf19..6b8ba9f34 100644 --- a/django/README.md +++ b/django/README.md @@ -60,6 +60,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 django: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + # License View [license information](https://github.com/django/django/blob/master/LICENSE) for the software contained in this image. diff --git a/golang/README.md b/golang/README.md index dc7b1bb02..876179d7a 100644 --- a/golang/README.md +++ b/golang/README.md @@ -74,6 +74,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 golang: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + # License View [license information](http://golang.org/LICENSE) for the software contained in this image. diff --git a/iojs/README.md b/iojs/README.md index 3459f03a2..a3b7154bc 100644 --- a/iojs/README.md +++ b/iojs/README.md @@ -52,6 +52,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 iojs: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + ## `iojs:slim` This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `iojs`. Unless you are working in an environment where *only* the iojs image will be deployed and you have space constraints, we highly recommend using the default image of this repository. diff --git a/maven/README.md b/maven/README.md index 8efde8f80..d666f0e36 100644 --- a/maven/README.md +++ b/maven/README.md @@ -47,6 +47,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 maven: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + # License View [license information](https://www.apache.org/licenses/) for the software contained in this image. diff --git a/mono/README.md b/mono/README.md index 7cfe1426f..a87cbff16 100644 --- a/mono/README.md +++ b/mono/README.md @@ -60,6 +60,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 mono: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + # License This Docker Image is licensed with the Expat License. See the [Mono Project licensing FAQ](http://www.mono-project.com/docs/faq/licensing/) for details on how Mono and associated libraries are licensed. diff --git a/node/README.md b/node/README.md index 193ebd3d8..ca508daa2 100644 --- a/node/README.md +++ b/node/README.md @@ -62,6 +62,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 node: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + ## `node:slim` This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `node`. Unless you are working in an environment where *only* the node image will be deployed and you have space constraints, we highly recommend using the default image of this repository. diff --git a/perl/README.md b/perl/README.md index 59f05757a..9f3ae996a 100644 --- a/perl/README.md +++ b/perl/README.md @@ -1,19 +1,9 @@ # Supported tags and respective `Dockerfile` links -- [`latest`, `5`, `5.20`, `5.20.2` (*5.020.002-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.020.002-64bit/Dockerfile) -- [`5.18`, `5.18.4` (*5.018.004-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.018.004-64bit/Dockerfile) -- [`5.16`, `5.16.3` (*5.016.003-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.016.003-64bit/Dockerfile) -- [`5.14`, `5.14.4` (*5.014.004-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.014.004-64bit/Dockerfile) -- [`5.12`, `5.12.5` (*5.012.005-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.012.005-64bit/Dockerfile) -- [`5.10`, `5.10.1` (*5.010.001-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.010.001-64bit/Dockerfile) -- [`5.8`, `5.8.9` (*5.008.009-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.008.009-64bit/Dockerfile) -- [`threaded`, `5-threaded`, `5.20-threaded`, `5.20.2-threaded` (*5.020.002-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.020.002-64bit,threaded/Dockerfile) -- [`5.18-threaded`, `5.18.4-threaded` (*5.018.004-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.018.004-64bit,threaded/Dockerfile) -- [`5.16-threaded`, `5.16.3-threaded` (*5.016.003-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.016.003-64bit,threaded/Dockerfile) -- [`5.14-threaded`, `5.14.4-threaded` (*5.014.004-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.014.004-64bit,threaded/Dockerfile) -- [`5.12-threaded`, `5.12.5-threaded` (*5.012.005-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.012.005-64bit,threaded/Dockerfile) -- [`5.10-threaded`, `5.10.1-threaded` (*5.010.001-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.010.001-64bit,threaded/Dockerfile) -- [`5.8-threaded`, `5.8.9-threaded` (*5.008.009-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150503.0/5.008.009-64bit,threaded/Dockerfile) +- [`latest`, `5`, `5.22`, `5.22.0` (*5.022.000-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150602.0/5.022.000-64bit/Dockerfile) +- [`5.20`, `5.20.2` (*5.020.002-64bit/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150602.0/5.020.002-64bit/Dockerfile) +- [`threaded`, `5-threaded`, `5.22-threaded`, `5.22.0-threaded` (*5.022.000-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150602.0/5.022.000-64bit,threaded/Dockerfile) +- [`5.20-threaded`, `5.20.2-threaded` (*5.020.002-64bit,threaded/Dockerfile*)](https://github.com/perl/docker-perl/blob/r20150602.0/5.020.002-64bit,threaded/Dockerfile) For more information about this image and its history, please see the [relevant manifest file (`library/perl`)](https://github.com/docker-library/official-images/blob/master/library/perl) in the [`docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images). diff --git a/pypy/README.md b/pypy/README.md index 8472ef22c..f060ac928 100644 --- a/pypy/README.md +++ b/pypy/README.md @@ -60,6 +60,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 pypy: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + ## `pypy:slim` This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `pypy`. Unless you are working in an environment where *only* the pypy image will be deployed and you have space constraints, we highly recommend using the default image of this repository. diff --git a/python/README.md b/python/README.md index 974e12d70..6d7130c1b 100644 --- a/python/README.md +++ b/python/README.md @@ -68,6 +68,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 python: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + ## `python:slim` This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `python`. Unless you are working in an environment where *only* the python image will be deployed and you have space constraints, we highly recommend using the default image of this repository. diff --git a/rails/README.md b/rails/README.md index b0741be44..5bc0e5af3 100644 --- a/rails/README.md +++ b/rails/README.md @@ -61,6 +61,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 rails: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + # License View [license information](https://github.com/rails/rails#license) for the software contained in this image. diff --git a/ruby/README.md b/ruby/README.md index 2037b42ec..c8f23503e 100644 --- a/ruby/README.md +++ b/ruby/README.md @@ -64,6 +64,10 @@ This is the defacto image. If you are unsure about what your needs are, you prob 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 ruby: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)). + +Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your `Dockerfile` to inherit from a non-`onbuild` variant and copy the commands from the `onbuild` variant `Dockerfile` (moving the `ONBUILD` lines to the end and removing the `ONBUILD` keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your `Dockerfile` as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-`ONBUILD` steps). + ## `ruby:slim` This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `ruby`. Unless you are working in an environment where *only* the ruby image will be deployed and you have space constraints, we highly recommend using the default image of this repository.