& 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
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.
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
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
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”
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 ;)
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
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)
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
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
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
the image + version <image name>:<version> E.g. mcr.microsoft.com/dotnet/core/runtime:3.0 Can create/use images without the :<version> portion, this the “latest” tag
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
you’re logged in to correct registry Ensure you’re image is tagged <registry>*/<repository name>/<image>:<version> 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
or public repositories Most support building container images DockerHub – default registry used by tooling Container registries from cloud providers – Azure Container Registry
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
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
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
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
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
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
based applications across multiple servers Provides many features you’d expect in a application platform Autoscaling Resilient applications Rolling deployments
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