Slide 1
Slide 1 text
@shahiddev
Docker/Containers
What, Why & How
Shahid Iqbal
@shahiddev
https://linkedin.shahid.dev
Slide 2
Slide 2 text
@shahiddev
Who am I?
Freelance Azure/.NET/Kubernetes hands-on consultant
Run Docker & Kubernetes workshops
Developer/Architect for 10+ years & Microsoft Azure MVP
UK based but work globally
Co-organise a .NET meetup in the UK
@shahiddev on Twitter
https://linkedin.shahid.dev
https://blog.headforcloud.com
Slide 3
Slide 3 text
@shahiddev
Agenda
Container background
Benefits
How to’s
Windows containers
Orchestration
Slide 4
Slide 4 text
@shahiddev
Assumptions
You are very new to Docker
or
You have some basic knowledge but want to fill in the gaps
This is an introductory talk ☺
It will be fast paced – you should be equipped to go away and dive deeper.
Slide 5
Slide 5 text
@shahiddev
Containers aren’t really new
Namespaces
Virtualize system
resources, like the
file system or
networking for each
process
Cgroups
Limit the resources,
such as CPU and
memory, that each
process can use
Build on Linux constructs (Cgroups and Namespaces) to create processes in isolation
Slide 6
Slide 6 text
@shahiddev
Docker was born
Docker took the primitives and packaged them into a
product
This helped lead to the widespread adoption of
containers
Slide 7
Slide 7 text
@shahiddev
But what are containers…
Think of them like lightweight VMs*
Package an application along with all of its dependencies into a self contained image
Generally smaller than VM images
Fast to start (seconds) vs VM boot time
Shared OS kernel may reduce licensing costs
Your CI system would output containers rather than deployment binaries/packages
*They’re not really and don’t have necessarily have the same isolation guarantees
Slide 8
Slide 8 text
@shahiddev
Docker vs VMs
Slide 9
Slide 9 text
@shahiddev
Why containers?
Isolation – each container encapsulates it’s own dependencies
Lightweight – share the same kernel so don’t virtualise the whole stack
Can run many containers on a single machine
Fast to start
Portable – can run them anywhere that has the runtime
Simplifies provisioning of servers – no need to install many dependencies
No more “works on my machine”
Slide 10
Slide 10 text
@shahiddev
Developer workflow benefits
Can run multiple versions of frameworks without conflicts
Less setup required for new dev machines - quicker to onboard developer
Front-end folks can run the backend locally if required
Back-end folks don’t need to install NPM
see VS Code demo later ;)
Slide 11
Slide 11 text
@shahiddev
Docker vs other container technologies
Rkt*
Katacontainers
LXC/LXD
*Archived by the CNCF in August 2019
Slide 12
Slide 12 text
@shahiddev
Open Container Initiative (OCI)
Collaboration between Docker, CoreOs* and other companies to create an open
standard for container image and container runtimes.
This allows for different container formats/implementations to co-exist and work
together
*Acquired by RedHat who were themselves acquired by IBM
Slide 13
Slide 13 text
@shahiddev
Container vs Image
Image is a blueprint/template comprised of an OS + app layers
Container is a running instance of the image
You can create multiple containers from the same image (i.e. multiple instances of an
application)
Slide 14
Slide 14 text
@shahiddev
Images are layered
Allows for images to be built on top of existing images
Layers can be cached to reduce disk space and bandwidth consumption
Layers are read-only in an image
When you create a container from an image you get a r/w layer on top of the r/o
layers
Slide 15
Slide 15 text
@shahiddev
Image layers
Slide 16
Slide 16 text
@shahiddev
State within a container
Can write to the “local” filesystem
Changes will be lost when the container is removed
If you need to write to local file system - use Volumes
Slide 17
Slide 17 text
@shahiddev
Volumes
Volumes allow for container state to exist beyond the lifetime of a container
State can be shared between multiple containers
Volumes can be mounted as read/write, readonly or temporary
Can load folder from local machine into container so you can share state between
local machine and a container
Slide 18
Slide 18 text
@shahiddev
Container based application workflow
Container Host
Developer
machine
Slide 19
Slide 19 text
@shahiddev
Building images
Slide 20
Slide 20 text
@shahiddev
Getting started
Use Docker desktop on Windows or Mac
Installs the Docker engine and CLI
Free community edition
https://www.docker.com/products/docker-desktop
Slide 21
Slide 21 text
@shahiddev
Docker file basics
Text file describes steps to build container
Typically each line of file creates a new layer
By convention called dockerfile (with no extension) in root of project
Order of statements is important
Slide 22
Slide 22 text
@shahiddev
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 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/runtime:3.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "hello-docker.dll"]
Slide 23
Slide 23 text
@shahiddev
Building docker images
Docker build –t
E.g.
Docker build –t k8s:1.0 .
Slide 24
Slide 24 text
@shahiddev
Tags
Tags are a combination of the name of the image + version
![]()
:
E.g.
mcr.microsoft.com/dotnet/core/runtime:3.0
Can create/use images without the : portion, this the “latest” tag
Slide 25
Slide 25 text
@shahiddev
Tags
Avoid running “latest” tag in any production scenario
Tag names need to factor in code changes + changes in underlying base images
Build-id is good tag candidate
- Allows for tracking back to specific CI build
Slide 26
Slide 26 text
@shahiddev
Running docker images
Docker run
Many parameters to change behaviour
--name Allows you to specify a name for the container
-d Detached/Daemon mode
-p: Maps local port to container port
…
Slide 27
Slide 27 text
@shahiddev
Pushing images to a registry
Docker push
Ensure you’re logged in to correct registry
Ensure you’re image is tagged *//![]()
:
E.g.
Docker tag k8s:1.0 shahiddev/k8s:1.0
Docker push shahiddev/k8s:1.0
*If you’re pushing to DockerHub you don’t need the registry portion
Slide 28
Slide 28 text
@shahiddev
Container registries
Repository for hosting your container images
Private or public repositories
Most support building container images
DockerHub – default registry used by tooling
Container registries from cloud providers – Azure Container Registry
Slide 29
Slide 29 text
@shahiddev
DEMO
Container basics
Slide 30
Slide 30 text
@shahiddev
Windows containers
Use familiar Docker tooling and commands to create and run containers
Windows containers can only run on Windows
“Docker-rise” full .NET framework applications
License savings by running multiple Windows containers on a single server
Image sizes can be substantially larger than Linux containers
Slide 31
Slide 31 text
@shahiddev
Windows containers
Slide 32
Slide 32 text
@shahiddev
Windows containers OS options
Physical Machine/VM
Windows Server 2016+ Windows 10 Pro/Enterprise*
Host OS
Windows Server
Core
Nano Server
Windows Server
Core
Nano Server
Guest OS
*dev purposes only
Slide 33
Slide 33 text
@shahiddev
Windows server guest OS decisions
Nano Server -> New applications/services
o Smaller image
o 64bit only
o No full .NET framework
Windows Server Core -> Existing/legacy applications
o Full .NET framework
o Webforms/COM interop etc
Slide 34
Slide 34 text
@shahiddev
Hyper-v containers
Reminder – containers don’t give the same level of isolation as VMs
Regulatory requirements may mandate hypervisor level isolation
Running other peoples code – want an extra level of protection
Windows containers can run in 2 modes
Slide 35
Slide 35 text
@shahiddev
Hyper-v containers
Slide 36
Slide 36 text
@shahiddev
Hyper-v containers
Same container image
Add "- -isolation=hyperv" flag to the Docker run command
Slide 37
Slide 37 text
@shahiddev
Hyper-v container downsides
Containers running with hyper-v isolation incur an additional Windows license
Container start up times are slower (by a few seconds)
Container overhead is higher
Still much faster and less resource intensive than full VMs
Slide 38
Slide 38 text
@shahiddev
VS Code Remote - Containers
Development “inside” a container
Don’t need to have tools/sdks installed on local machine
Can work with a remote Docker host
*Windows containers not currently supported
Slide 39
Slide 39 text
@shahiddev
VS Code Remote - Containers
Slide 40
Slide 40 text
@shahiddev
Running containers in the cloud
Spin up VM and run containers on VM
Use PaaS service to run container – Azure App Service for containers, ECS
Serverless container platform – Azure Container Instances, AWS Fargate
Orchestration platform – Docker Swarm, Kubernetes
Slide 41
Slide 41 text
@shahiddev
Serverless container platform
Azure Container Instances
No need to provision servers first
Pay per second for running containers
Recent price cuts – cost is similar to small VMs/PaaS sku
Slide 42
Slide 42 text
@shahiddev
DEMO
VS Code remote containers
Containers in the cloud
Windows containers
Slide 43
Slide 43 text
@shahiddev
Orchestration Running multiple
containers
Slide 44
Slide 44 text
@shahiddev
How to manage multiple containers
Single server Cluster of servers
Slide 45
Slide 45 text
@shahiddev
Docker Compose
Declarative YAML file to describe containers you want to run
Containers are spun up and removed as a single unit
Volumes and networks are composed with containers to provide architecture
Great for some developer workflows to co-ordinate creation of containers for
testing/developing
Slide 46
Slide 46 text
@shahiddev
Docker Swarm
Docker’s answer to managing containers across a number of servers
Easy to get started with but largely overtaken by Kubernetes
Slide 47
Slide 47 text
@shahiddev
Kubernetes
Open source container orchestrator
Helps you run container based applications across multiple servers
Provides many features you’d expect in a application platform
Autoscaling
Resilient applications
Rolling deployments
Slide 48
Slide 48 text
@shahiddev
DEMO
Orchestration - Kubernetes
Slide 49
Slide 49 text
@shahiddev
Summary
Containers can dramatically simplify your deployment workflow.
Managing legacy applications by using containers can provide a consistent approach
for old and new applications
Windows containers may give cost savings by reducing the number of Windows
Server licenses required to run many smaller apps.
May not need to go to full fledged orchestration (Kubernetes) – there is a significant
organisational cost, training, knowledge to run Kubernetes.
Security is an important factor – please don’t ignore
Slide 50
Slide 50 text
@shahiddev
Useful resources
http://www.katacoda.com
https://bit.ly/k8s-ndc
Slide 51
Slide 51 text
@shahiddev
Thank you!
Shahid Iqbal
@shahiddev on Twitter
https://linkedin.shahid.dev
https://blog.headforcloud.com
Slides:
https://bit.ly/shahiddev-docker