Docker, Virtual-Desktop and build-docker-image

Previously, my work platform involved using development, testing, and production environments. Docker is relatively new to me. As I also held a system administrator role, the characterization of Docker as "lightweight and simple" by supporters in the programming development community left me puzzled for a while. Here's a brief explanation of the differences between VMs, Docker, and Virtual Desktops as I understand them.

The platforms most people commonly interact with are standalone systems, which typically include Windows, Mac, Android, and iOS. In the early Unix era, the system architecture consisted of a Host and Terminals. Terminals are lightweight systems with basic functions, which can also be seen today in devices like the Raspberry Pi.

When work requires several systems to perform different tasks, having a separate hardware device for each can be wasteful. This led to the development of Hypervisor and VM (Virtual Machine) architectures.

Sometimes institutions need to provide public computers for authorized users without leaving user data on the machines. Virtual Desktop imports user settings to the client computer upon login, addressing this need.

Actually, Docker is not as lightweight as it seems. Its containers include the OS and all installed programs, not just the app and its dependencies.

Docker is suitable for packaging tests but does not offer the same level of OS operability to users as VMs do. Therefore, Docker's base OS is typically Alpine, which provides basic Linux functionalities.  Below are the original sizes of the Alpine and Mint (Ubuntu) images.

Creating a Docker Image

I often conduct platform tests, so I prefer not to use images that are too large. For testing development functions, I favor ultra-small OS like Alpine. Its commands are somewhat different from common Linux commands, but fortunately, the concepts are similar.

There are many quick-start courses available online. Since I tend to prefer official website data over sifting through my bookmarks, let's begin this note from the initialization. Docker has two configuration methods: one is operational, and the other is programmatic.

Example: Create a container that reads user input.

Operational：

Download the basic operating system. You can find pre-made system or function packages created by others on https://hub.docker.com/. System types such as Alpine, Ubuntu. Function packages such as Python, NGINX. (I have already logged in to Docker).

docker pull alpine

Establish container, execute system.

ducker run -it --name testInput alpine /bin/ash

Install Python. 

  apk add python3 py3-pip
  ln -sf python3 /usr/bin/python
  

Write test program.

vi /home/printInput.py

(exit docker: ctrl+p , ctrl+q )

Save the modified OS as a new image; the image name must be all lowercase.

docker container ls 

docker commit 0340edf99261 atfuture7/testinput

Launch a new container with the new image to run a custom-written Python script.

docker run -it -rm atfuture7/testinput python3 /home/printInput.py

Execution :

ref: 

https://docs.docker.com/engine/reference/run/

https://stackoverflow.com/questions/32353055/how-to-start-a-stopped-docker-container-with-a-different-command

Programmatic:

Running Docker initialization in a new directory.

docker init 

Next, a guided process will assist in creating basic data. I chose the "Other option" as a skeleton.

Other - general purpose starting point for containerizing your application

After initialization, Docker creates 4 basic files.

The current version recommends using Compose to combine different resources.

docker compose up --build

Here, I'll explain a simplified Dockerfile, primarily aimed at customizing images.

docker build -t testinupt2 . 

The Dockerfile modifies the inherited image and can be divided into different stages.

ref: https://docs.docker.com/build/building/multi-stage/

DOCKER_BUILDKIT determines whether to use BuildKit.

    FROM alpine:latest as base
    FROM base as build
    FROM base AS final
    

Modify the build stage to execute a Python script.

If using the old build method, all stages will be executed. By adopting stages, the builder will proceed in the order of inheritance, with the final product being the specified stage.

Note: During compilation, the original image name was set to "testinput2." However, a "pull access denied for testinput2" error kept occurring during execution. Deleting and rebuilding the image did not update it. Both the "created time" and "Image hierarchy" were not of the new version. I suspect it's because when logged in, the image name needs to be [account name]/[image name]. Without [account name], it's considered not part of one's account directory images.Although this image has not been pushed to the cloud.

docker build --target build -t atfuture7/testinupt2 .

Launching a new container with a custom image to run a self-written Python script. 

docker run -it -rm atfuture7/testinput2 

Running the new image.

Since the entrypoint is defined in the Dockerfile, there's no need to specify a run command when executing the image.

docker run -it  atfuture7/testinput2

My sample in GitHub: https://github.com/atfuture7/testcode/tree/master/docker/01_docker_skeleton