Docker Concepts - Gary-Moore/developmentwiki GitHub Wiki
Dockerfile
The Dockerfile file is used by the docker build command to create a container image. This file is a plaintext file named Dockerfile that does not have an extension.
First, set the base image, then set the working directory and the try point of the docker container to run from.
Dockerfile file for asp.net core app
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
https://docs.docker.com/engine/examples/dotnetcore/
https://docs.microsoft.com/en-us/dotnet/core/docker/build-container
Swarm mode
True native clustering of docker engines called a swarm. Docker engines in a swarm are running in swarm mode.
It consists of one or more worker nodes and one or more manager nodes. Manager nodes look after the state of the cluster, managing membership and task delegation of worker nodes. They are H/A and it is recommended to have an odd number of them: 3-5. Only one is a leader.
The Raft Consensus Algorithm is used by the manager nodes to manage the global cluster state.
Services require swarm mode to be activated.
https://docs.docker.com/engine/swarm/
https://docs.docker.com/engine/swarm/key-concepts/
https://docs.docker.com/engine/swarm/raft/
Task
A task is the atomic unit of scheduling within a swarm. A task carries a Docker container and the commands to run inside the container. Manager nodes assign tasks to worker nodes according to the number of replicas set in the service scale.
https://docs.docker.com/glossary/?term=task
Docker Services
A service is the definition of how you want to run your application containers in a swarm. At the most basic level a service defines which container image to run in the swarm and which commands to run in the container. For orchestration purposes, the service defines the “desired state”, meaning how many containers to run as tasks and constraints for deploying the containers.