Skip to content

Remove unnecessary package cache files for apt/pip, implement multistage builds to minimize container image #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
rgschmitz1 opened this issue Jun 9, 2022 · 2 comments · Fixed by #62
Closed
3 tasks done

Comments

@rgschmitz1
Copy link
Contributor

rgschmitz1 commented Jun 9, 2022

My actions before raising this issue

Expected Behaviour

I'd recommend cleaning up the cache files from apt and pip. tox testing can be performed without additional final image padding by using multistage build mechanisms.

Current Behaviour

Package cache files from apt and pip are creating larger container images. tox also significantly increase in the final container image size as it creates a virtual environment and installs several packages.

Possible Solution

  • Remove the apt cache files by chaining install and cache remove commands (this is the command found in the docker best practices documentation)
RUN apt-get -qy update && \
	apt-get -qy install ${ADDITIONAL_PACKAGE} && \
	rm -rf /var/lib/apt/lists/*
  • Remove the pip cache by using --no-cache-dir flag when installing with pip.
RUN pip install --no-cache-dir -r requirements.txt
  • Implement three build stages in the Dockerfile, (e.g. builder, testing, final), label the initial python base image FROM python:<tag> AS builder starting the testing stage using FROM builder AS testing, and starting the final stage using FROM builder AS final, this will still run tests but avoids the unnecessary .tox directory left behind from testing.
FROM openfaas/of-watchdog:0.9.6 AS watchdog
FROM python:3.7-slim-buster AS builder

<snippet>

FROM builder AS tester

ARG TEST_COMMAND=tox
ARG TEST_ENABLED=true
RUN [ "$TEST_ENABLED" = "false" ] && echo "skipping tests" || eval "$TEST_COMMAND"

FROM builder AS final

<snippet>

Doing the above reduced the deployed container image size by 28% for the python3-flask-debian template (results will likely vary a depending on additional packages installed). Build time didn't appear to be affected by modifications.

Steps to Reproduce (for bugs)

  1. Copy Dockerfile from gist.
  2. Use faas-cli to build a container image from above Dockerfile.
  3. Use faas-cli to build a container image with an unmodified Dockerfile.
  4. Compare container image sizes.

Context

I'm a graduate student working on a masters capstone comparing performance and cost of cloud native applications running with open sourced software to proprietary solutions from cloud vendors. I'm also working with a company (BioDepot LLC) that uses Docker for packaging their software. I'd like to pass along some helpful tips that I've learned from maintaining container images.

Your Environment

  • FaaS-CLI version ( Full output from: faas-cli version ):
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  b1c09c0243f69990b6c81a17d7337f0fd23e7542
 version: 0.14.2
  • Docker version docker version (e.g. Docker 17.0.05 ):
Docker version 20.10.14, build a224086
  • Are you using Docker Swarm or Kubernetes (FaaS-netes)?
    Kubernetes

  • Operating System and version (e.g. Linux, Windows, MacOS):

NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
@alexellis
Copy link
Member

@LucasRoesler raised a PR for this, it needs a rebase, then we can get this merged.

Did you already take a look at #59?

@rgschmitz1
Copy link
Contributor Author

Hi @alexellis , PR #59 is exactly what I was looking for. Thanks for the support again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants