Related

Why am I getting a Deploy Error: Health Checks? Question Question
How can I see the build logs for my application if the build was skipped for a deployment? Question Question

Question

App spec does not use Docker container caching

Posted October 22, 2020 114 views
DigitalOcean App Platform

The only thing I changed in my App Spec file is database username. Yet it triggered full rebuild of the Docker, which takes around 10 minutes for 1 service + 10 minutes for a job (both using the same Dockerfile).

There are two issues here:

Issue 1. Docker build cache is not used.

Issue 2. Docker build result is not shared between the job and the service.

This makes me wait for 20 minutes every time I experiment with the App spec, even though there is nothing that would indicate the need to rebuild from scratch:

  • no build time args changes
  • no Dockerfile changes

Is this expected behavior?

Add a comment
ReWild
By:
ReWild

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers
pistle2020 October 22, 2020

From your Dockerfile, if you append lines to your Dockerfile, or change the code being built, there’s only one line that could be cached:

RUN mkdir /code
After that, you perform a:

COPY . /code
Since you have changed your Dockerfile, the contents of . have changed (the Dockerfile is part of .) and therefore the COPY needs to be performed again, generating a new layer. Once you generate a new layer, every following layer no longer has a cache and needs to be rebuild.

To improve caching, consider placing the lines that change less towards the top of your Dockerfile. That would leave the COPY . /code line at the very end of the file since it will change almost every time.

Reply Report
  • ReWild October 22, 2020

    Thanks @pistle2020! Please check: I have many instructions before the first COPY happens. The very beginning of my Dockerfile is as follows, am I doing it wrong and causing building from scratch all the times? If so, how could I improve?

    FROM php:7.4.11-fpm

# procps and htop is needed for development only
RUN apt-get update \
  && apt-get install -y \
    nano \
    bash-completion \
    zsh \
    zsh-syntax-highlighting \
    procps \
    htop \
    zip \
    libpng-dev \
    unzip \
    lsb-release \
    wget \
    gnupg2 \
    libpq-dev \
    libtidy-dev \
    libyaml-dev \
    lsof \
    autossh \
    locales \
    webp \
    jpegoptim \
    optipng \
  && usermod -s /usr/bin/zsh $(whoami) \
  && echo "source /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh" >> ~/.zshrc
  # && sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# Planned supported languages: Spanish, Portuguese, French, Russian, Manadrin
RUN echo "ru_RU.UTF-8 UTF-8" >> /etc/locale.gen \
    echo "fr_FR.UTF-8 UTF-8" >> /etc/locale.gen \
    echo "pt_BR.UTF-8 UTF-8" >> /etc/locale.gen \
    echo "es_ES.UTF-8 UTF-8" >> /etc/locale.gen \
    echo "zh_CN.UTF-8 UTF-8" >> /etc/locale.gen \
    && locale-gen \
    && echo "LANG=\"en_US.UTF-8\"" >> /etc/default/locale \
    && echo "export LANG=en_US.UTF-8" >> ~/.zshrc


RUN apt-get update \
  && apt-get install -y python3-pip \
  && pip3 install supervisor

RUN apt-get install -y zlib1g-dev libicu-dev g++ \
  && docker-php-ext-configure intl \
  && docker-php-ext-install intl

RUN docker-php-ext-install pdo_pgsql

RUN docker-php-ext-install tidy \
    && docker-php-ext-enable tidy

RUN docker-php-ext-install gd \
    && docker-php-ext-enable gd

RUN pecl install redis-5.3.1 \
    && docker-php-ext-enable redis

RUN pecl install yaml \
    && echo "extension=yaml.so" > /usr/local/etc/php/conf.d/ext-yaml.ini \
    && docker-php-ext-enable yaml

RUN docker-php-ext-install pcntl \
    && docker-php-ext-enable pcntl

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version
    Reply Report
snormoredo October 22, 2020

@ReWild 👋

Thanks for surfacing this — it’s not intended behavior. This is related to the job component specifically, where we were not excluding some of the non-build context from the reuse keys. We’ve deployed a fix for this, and is working as expected now. Let us know if you hit any more problems or if it’s not completely resolved for you.

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help