Estimated reading time: 13 minutes
- Docker Ubuntu 16.04 Python 3.7
- Docker Ubuntu 18.04 Python 3.7
- Docker Ubuntu With Python 3.7 64-bit
- Docker Image Ubuntu With Python 3.7
$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE python 3.7-alpine b2c276538711 3 days ago 97.7MB hello-world latest fce289e99eb9 12 months ago 1.84kB There are currently two images: the hello-world image we previously downloaded and one for python we just built. And the official Python Docker images based off of Debian Buster also give you the full range of Python releases. The official Docker Python image in its slim variant—e.g. Python:3.8-slim-buster—is a good base image for most use cases. It’s 60MB when downloaded, 180MB when uncompressed to disk, it gives you the latest Python releases,.
Work through the orientation and setup in Get started Part 1 to understand Docker concepts.
Before we start building images, ensure you have enabled BuildKit on your machine.BuildKit allows you to build Docker images efficiently. For more information,see Building images with BuildKit.
BuildKit is enabled by default for all users on Docker Desktop. If you haveinstalled Docker Desktop, you don’t have to manually enable BuildKit. If you arerunning Docker on Linux, you can enable BuildKit either by using an environmentvariable or by making BuildKit the default setting.
To set the BuildKit environment variable when running the
docker build command,run:
To enable docker BuildKit by default, set daemon configuration in
/etc/docker/daemon.json feature to
true and restart the daemon.If the
daemon.json file doesn’t exist, create new file called
daemon.json and then add the following to the file.
Restart the Docker daemon.
Now that we have a good overview of containers and the Docker platform, let’s take a look at building our first image. An image includes everything needed to run an application - the code or binary, runtime, dependencies, and any other file system objects required.
Docker Ubuntu 16.04 Python 3.7
To complete this tutorial, you need the following:
- Python version 3.8 or later. Download Python
- Docker running locally. Follow the instructions to download and install Docker
- An IDE or a text editor to edit files. We recommend using Visual Studio Code.
Let’s create a simple Python application using the Flask framework that we’ll use as our example. Create a directory in your local machine named
python-docker and follow the steps below to create a simple web server.
Now, let’s add some code to handle simple web requests. Open this working directory in your favorite IDE and enter the following code into the
Test the application
Let’s start our application and make sure it’s running properly. Open your terminal and navigate to the working directory you created.
To test that the application is working properly, open a new browser and navigate to
Switch back to the terminal where our server is running and you should see the following requests in the server logs. The data and timestamp will be different on your machine.
Create a Dockerfile for Python
Now that our application is running properly, let’s take a look at creating a Dockerfile.
A Dockerfile is a text document that contains the instructions to assemble aDocker image. When we tell Docker to build our image by executing the
docker buildcommand, Docker reads these instructions, executes them, and creates a Dockerimage as a result.
Let’s walk through the process of creating a Dockerfile for our application. Inthe root of your project, create a file named
Dockerfile and open this file inyour text editor.
Docker Ubuntu 18.04 Python 3.7
What to name your Dockerfile?
The default filename to use for a Dockerfile is
Dockerfile (without a file-extension). Using the default name allows you to run the
docker build commandwithout having to specify additional command flags.
Some projects may need distinct Dockerfiles for specific purposes. A commonconvention is to name these
<something>.Dockerfile.Such Dockerfiles can then be used through the
-f shorthand)option on the
docker build command. Refer to the“Specify a Dockerfile” sectionin the
docker build reference to learn about the
We recommend using the default (
Dockerfile) for your project’s primaryDockerfile, which is what we’ll use for most examples in this guide.
The first line to add to a Dockerfile is a
# syntax parser directive.While optional, this directive instructs the Docker builder what syntax to usewhen parsing the Dockerfile, and allows older Docker versions with BuildKit enabledto upgrade the parser before starting the build. Parser directivesmust appear before any other comment, whitespace, or Dockerfile instruction inyour Dockerfile, and should be the first line in Dockerfiles.
We recommend using
docker/dockerfile:1, which always points to the latest releaseof the version 1 syntax. BuildKit automatically checks for updates of the syntaxbefore building, making sure you are using the most current version.
Next, we need to add a line in our Dockerfile that tells Docker what base imagewe would like to use for our application.
Docker images can be inherited from other images. Therefore, instead of creating our own base image, we’ll use the official Python image that already has all the tools and packages that we need to run a Python application.
To learn more about creating your own base images, see Creating base images.
To make things easier when running the rest of our commands, let’s create a working directory. This instructs Docker to use this path as the default location for all subsequent commands. By doing this, we do not have to type out full file paths but can use relative paths based on the working directory.
Usually, the very first thing you do once you’ve downloaded a project written in Python is to install
pip packages. This ensures that your application has all its dependencies installed.
Before we can run
pip3 install, we need to get our
requirements.txt file into our image. We’ll use the
COPY command to do this. The
COPY command takes two parameters. The first parameter tells Docker what file(s) you would like to copy into the image. The second parameter tells Docker where you want that file(s) to be copied to. We’ll copy the
requirements.txt file into our working directory
Once we have our
requirements.txt file inside the image, we can use the
RUN command to execute the command
pip3 install. This works exactly the same as if we were running
pip3 install locally on our machine, but this time the modules are installed into the image.
At this point, we have an image that is based on Python version 3.8 and we have installed our dependencies. The next step is to add our source code into the image. We’ll use the
COPY command just like we did with our
requirements.txt file above.
COPY command takes all the files located in the current directory and copies them into the image. Now, all we have to do is to tell Docker what command we want to run when our image is executed inside a container. We do this using the
CMD command. Note that we need to make the application externally visible (i.e. from outside the container) by specifying
Here’s the complete Dockerfile.
Just to recap, we created a directory in our local machine called
python-docker and created a simple Python application using the Flask framework. We also used the
requirements.txt file to gather our requirements, and created a Dockerfile containing the commands to build an image. The Python application directory structure would now look like:
Build an image
Now that we’ve created our Dockerfile, let’s build our image. To do this, we use the
docker build command. The
docker build command builds Docker images from a Dockerfile and a “context”. A build’s context is the set of files located in the specified PATH or URL. The Docker build process can access any of the files located in this context.
The build command optionally takes a
--tag flag. The tag is used to set the name of the image and an optional tag in the format
name:tag. We’ll leave off the optional
tag for now to help simplify things. If you do not pass a tag, Docker uses “latest” as its default tag.
Let’s build our first Docker image.
View local images
To see a list of images we have on our local machine, we have two options. One is to use the CLI and the other is to use Docker Desktop. As we are currently working in the terminal let’s take a look at listing images using the CLI.
To list images, simply run the
docker images command.
You should see at least two images listed. One for the base image
3.8-slim-buster and the other for the image we just built
As mentioned earlier, an image name is made up of slash-separated name components. Name components may contain lowercase letters, digits and separators. A separator is defined as a period, one or two underscores, or one or more dashes. A name component may not start or end with a separator.
An image is made up of a manifest and a list of layers. Do not worry too much about manifests and layers at this point other than a “tag” points to a combination of these artifacts. You can have multiple tags for an image. Let’s create a second tag for the image we built and take a look at its layers.
To create a new tag for the image we’ve built above, run the following command.
docker tag command creates a new tag for an image. It does not create a new image. The tag points to the same image and is just another way to reference the image.
Now, run the
docker images command to see a list of our local images.
You can see that we have two images that start with
python-docker. We know they are the same image because if you take a look at the
IMAGE ID column, you can see that the values are the same for the two images.
Let’s remove the tag that we just created. To do this, we’ll use the
rmi command. The
rmi command stands for remove image.
Note that the response from Docker tells us that the image has not been removed but only “untagged”. You can check this by running the
docker images command.
Our image that was tagged with
:v1.0.0 has been removed, but we still have the
python-docker:latest tag available on our machine.
In this module, we took a look at setting up our example Python application that we will use for the rest of the tutorial. We also created a Dockerfile that we used to build our Docker image. Then, we took a look at tagging our images and removing images. In the next module we’ll take a look at how to:
Help us improve this topic by providing your feedback. Let us know what you think by creating an issue in the Docker Docs GitHub repository. Alternatively, create a PR to suggest updates.
python, build, images, dockerfile
This article is written at 2021-03-22 so this conclusion will evolve as time passes.
Docker Ubuntu With Python 3.7 64-bit
Some of my articles are checked after 7 years, so be advised this choice will not be valid in a year. Although the reasoning and considerations to take in count will be the same.
I answer to the question: Why Carles, do you suggest to adopt Python 3.8, and not 3.9 or 3.7 for our Internal Automation Tools?.
Reliability and Maturity
If you look at page https://devguide.python.org/#status-of-python-branches you will see the next table:
So you can see that:
- Python 3.6 was released on 2016-12-23 and will get EOL on 2021-12-23.
- That’s EOL in 9 months. We don’t want to recommend that.
- Python 3.7 was released on 2018-06-27 and will get EOL 2023-06-27.
- That’s 2 years and 3 months from now. The Status of development is focus in Security bugfixes.
- Python 3.9 was released 2020-10-05 that’s 5 months approx from now.
- Honestly, I don’t recommend for Production a version of Software that has not been in the market for a year.
- Most of the bugs and security bugs appears before the first year.
- New features released, often are not widely fully tested , and bugs found and fixed, once a year has passed.
- Honestly, I don’t recommend for Production a version of Software that has not been in the market for a year.
- Python 3.8 was released on 2019-10-14.
- That means that the new features have been tested for a year and five months approximately.
- This is enough time to make appear most bugs.
- EOL is 2024-10, that is 3 years and 7 months from now. A good balance of EOL for the effort to standardize.
- Finally Python 3.8 is the Python mainline for Ubuntu 20.04 LTS.
- If our deploy strategy is synchronized, we want to use Long Time Support versions, of course.
So my recommendation would be, at least for your internal tools, to use containers based in Ubuntu 20.04 LTS with Python 3.8.
We know Docker images will be bigger using Ubuntu 20.04 LTS than using other images, but that disk space is really a small difference, and we get the advantage of being able to install additional packages in the Containers if we need to debug.
An Ubuntu 20.04 Image with Pyhton 3.8 and pytest, uses 540 MB.
Docker Image Ubuntu With Python 3.7
This is a small amount of space nowadays. Even if very basic Alpine images can use 25MB only, when you install Python they start to grow close to Ubuntu, to 360MB. The difference is not much, and if you used Alpine and you have suffered from Community packages being updated and becoming incompatible with wheel and you lost hours fixing the dependencies, you’ll really appreciate using my Ubuntu LTS packages approach.
Comments are closed.