26 September, 2020

Back to learning about Docker

A few months ago, I started learning about Docker. I got derailed with work projects and personal projects. Now that I have a bit of time, I want to get back to learning about Docker. 
I came across the book "Learn Docker in a Month of Lunches" by Elton Stoneman. Elton is putting a YouTube video each workday.

Day 1 - Understanding Docker and running Hello, World

Docker Commands covered in "Learn Docker in a Month of Lunches: Day 1"
  • docker version
  • docker-compose version
  • docker container run {name of image}
  • docker container run --interactive --tty {name of a image}
  • docker container ls
  • docker container top {container id}
  • docker container logs {container id}
  • docker container inspect {container id}
  • docker container ls --all
  • docker container run --detach --publish {local port:container port} {name of a image}
  • docker container status {container id}
  • docker container rm --force $(docker container ls --all --quite)

Notes from Day 1

  • The Docker Engine is the thing that runs the containers.
  • Container wraps the application and has resources that the container can access.
  • Containers are like a virtual environment in concept. One major difference is the container relies on the hosting machine's resources.
  • Containers stop automatically when the code in the container stops.
  • The Docker CLI can be configured to run against a local docker server or against a remote docker server

Day 2 - Building your own Docker images

Docker Commands covered in "Learn Docker in a Month of Lunches: 02"
  • docker image pull {name of image}
  • docker container run -d --name {name I want the container called} {name of image}
  • docker container logs {name of image}
  • docker container -rm {name of image}
  • docker container run --end {key=value pair} {name of image}
  • docker image build --tag {name} .
  • docker image ls
  • docker image history {image name}
  • docker system df

Notes from Day 2

  • Dockerfile contains the steps needed to build a Docker image. This kind of like install instructions or a runbook.
  • Docker commands follow a pattern
    • docker {command} {subcommand} - with Docker 1.13 the CLI was restructured
  • We talk about an image as a singular thing. An image is built up of many layers or parts. The images parts can be shared among other images.
  • Dockerfile
    • Dockerfile commands are capitalized (ie FROM, ENV, WORKDIR)
    • FROM line is required and is first-line
    • WORKDIR creates a working directory
    • CMD is the startup command for a container
  • The size listed from the command 'docker image ls' is the logical size.
  • A good practice is to structure the Dockerfile in such a way that the cache is used. This helps reduce the amount of time it takes to rebuild an image. 
    • The build process creates a hash for each step in the Dockerfile. This hash is used to help determine if that step needs to be rebuilt. Once the build encounters a step that needs to be rebuilt then all steps from that point to the last step will be rebuilt.
    • Put the commands that are least likely to change first

Day 3 - Packaging apps from source code into Docker images


Docker commands covered in "Learn Docker in a Month of Lunches: 03"
  • docker image build -t { name of image } .
  • docker container run { name of image }
  • docker network create { name of network }
  • docker container run --name { name of container} -d -p { host port }:{ container port } --network { name of network } { name of image }docker co
  • docker image ls -f reference={first image} -f reference={second image}
  • docker system prune

Notes from Day 3

  • Able to run commands inside Dockerfile
    • examples would be expanding zip files, running Windows installers, running a git command
  • Dockerfile can contain multi-stages
    • the final stage should contain only what is needed to run the application
    • the image size can change while the image is building
  • With Docker, it is possible to build an image from source code without having an SDK installed
  • Dockerfile
    • EXPOSE - port the container should listen on
  • Multistage Dockerfiles are important and useful
    • Helps standardize your project across various OS
    • Helps standardize processes across projects. Any project using a Dockerfile basically need two commands to get the project running
      • docker image build
      • docker container run
    • The use of layers within an image reduces the amount of time spent in rebuilding images
      • The first time an image is built all the layers need to be pulled, processed, and cached. After the first build, the cached layers can be used.
        • The order of the commands in the Dockerfile is important
      • The use of layers and cache comes at the expensive of hard drive space
        • Docker doesn't auto clean the cache
    • Separates the build & package tools from what is needed for deployment
  • Within a multistage Dockerfile, the steps in each stage should be organized so the steps change slowly or whose results are not like to change goes first.
    • You can only optimize so far. If one step relies on the results of a previous step then the steps must appear in that order.
      • An example would be the run command 


Resources





No comments:

Challenging myself to learn something new

I have recently set a big challenge for myself. I want to know about Machine Learning . To add to the challenge, I am trying out usin...