The Dockerfile¶

    The Dockerfile is simply a text document, containing all the commands that would be issued on thecommand-line to build an image - in short, the Dockerfile defines an environment.

    The Dockerfile is built automatically, and populated with appropriate commands (see below).However, you can also add any commands you wish to the Dockerfile, for example to installsystem packages, or to configure the environment.

    Important

    The Dockerfile executes its commands in sequence. This means that commands to install Node(for example) must come before commands to run Node packages.

    Hashes (#) in the Dockerfile indicate a comment. Sections within angle brackets areautogenerated by the Divio Cloud Control Panel, and may be updated or changed on deployment withoutwarning.

    Removing these wrapping tags will prevent a section being poulated or changed.

    These sections are in effect placeholders for Docker commands and configuration that will be usedto define the project later.

    The <WARNING> section¶

    The is always populated.

    1. # <WARNING>
    2. # be automatically replaced on deployment. You can disable
    3. # this functionality by simply removing the wrapping tags.
    4. # </WARNING>

    The <DOCKER_FROM> section¶

    This is determined by the project’s base project version. If you update the base project in theproject’s General Settings in the Control Panel, this will be updated on the next deployment.

    For a project built on the aldryn/base-project:py3-3.23 image, corresponding to the BaseProject: Python 3 v3.23:

    1. # <DOCKER_FROM>
    2. FROM aldryn/base-project:py3-3.23
    3. # </DOCKER_FROM>

    This section will be supplied by a that includes Nodecomponents, for example in the django CMS Sass Boilerplate.

    An example that uses other files supplied by the Boilerplate (such as install.sh) to set up theNode environment:

    The <NPM> section¶

    1. # <NPM>
    2. # package.json is put into / so that mounting /app for local
    3. # development does not require re-running npm install
    4. ENV PATH=/node_modules/.bin:$PATH
    5. COPY package.json /
    6. RUN (cd / && npm install --production && rm -rf /tmp/*)

    The <BOWER> section¶

    If both bower.json and .bowerrc are present in the root of the project, then thedeployment process will insert:

    1. # <BOWER>
    2. COPY bower.json .bowerrc /app/
    3. RUN bower install \
    4.     --verbose \
    5.     --allow-root \
    6.     --config.interactive=false
    7. # </BOWER>

    If either or requirements.txt are present in the root of the project, thenthe deployment process will insert appropriate instructions, that will handle installation of DivioCloud addons and other packages. The exact contents of this section will depend on the project; anexample for a Python 3 project:

    The <SOURCE> section¶

    The SOURCE section copies the project files to the /app directory of the container.

    1. # <SOURCE>
    2. COPY . /app
    3. # </SOURCE>

    We do this late in our Dockerfile by default. This is because it copies the entire repositoryinto the container, meaning that if anything is changed in the repository, it would invalidateall the following layers, which would have to be rebuilt from scratch rather than using cachedlayers. For reasons of economy, we keep this as late as possible.

    If other parts of the repository need to be copied into the container earlier in the process, theseshould be explicitly specified as required.

    The <GULP> section¶

    If gulpfile.js is present in the root of the project, then instructions will be inserted to runthe gulp build process:

    1. # <GULP>
    2. ENV GULP_MODE=production
    3. # </GULP>