Welcome into the containerized world
•Download as PPTX, PDF•
1 like•53 views
This document introduces containerization and microservice architecture. It discusses how containerization addresses issues with monolithic architectures by allowing independent deployment of services. Docker is presented as a tool for containerization, allowing packaging of applications and dependencies into shareable images. The document demonstrates Docker basics and discusses container orchestration with Kubernetes to manage fleets of containers across clusters.
More Related Content
What's hot
What's hot (20)
Similar to Welcome into the containerized world
Similar to Welcome into the containerized world (20)
Recently uploaded
Recently uploaded (20)
Welcome into the containerized world
- 1. Welcome into the containerized world
- 11. Problems of the Monolithic Architecture • People and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.
- 12. Microservice Architecture In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Process Isolation Independently deployable Lightweight Central Management Support diversity
- 17. What
- 18. Container = Process with Isolation OS Processor Memory Process C:ProgramDataxxx OS Container Process C: Internal Processes Processor Memory Maps PID Maps Memory C:ProgramDataDockerxxxx Maps Disk Mount Points Maps Port Me mo ry Classic Process Container
- 21. Docker Image • File • Package all your dependencies • Made out of layers • Idempotent • Shared = Storage Efficiency
- 22. Docker Registry & Docker Hub • Share Containers • Build Output • Search • Private/Public • Collaboration • On premise Registry
- 23. Demo • Getting Started PS C:UsersGeobarteam> docker version Client: Version: 17.12.0-ce API version: 1.35 Go version: go1.9.2 Git commit: c97c6d6 Built: Wed Dec 27 20:05:22 2017 OS/Arch: windows/amd64 Server: Engine: Version: 17.12.0-ce API version: 1.35 (minimum version 1.12) Go version: go1.9.2 Git commit: c97c6d6 Built: Wed Dec 27 20:12:29 2017 OS/Arch: linux/amd64 Experimental: true Linux !
- 24. Container Orchestration • Containers means • Packaging Applications one by one • Many Packages • Running on Many VM => Need for Orchestration • Ochestrators • Horizontal scaling • Self-Healing • Binpacking • Rollouts & Rollbacks • Storage Orchestration
- 25. Kubernetes https://kubernetes.io/ - Google => Datacenter OS - 2014 => Open Source
- 27. Demo@github: https://github.com/geobarteam/docker-demo Docker: https://docs.docker.com/ Kubernetes https://kubernetes.io/docs Azure Kubernets Service (AKS): https://docs.microsoft.com/en- us/azure/aks/
Editor's Notes
- Since last 2 decade we are using Monolithic Architecture. Where entire code base will be single unit and for each new release all code will be deployed each time there is a new release Biggest advantage is its simple at first=> Single Database One code base made out of Layers Everything is deployed together Runs fine on monolithic infrastructure Problems => Bottlenecks
- The way we create software and host it as dramatically changed over the last decades. This was driven by the ever increasing demands our world set on IT. If you compare what the requirement where for a piece of software 20 years ago and
- Every large IT organization I have seen so far in my career has had large project teams that spend almost all their time engaged in communication overhead of one sort or another. It is no exaggeration to say it takes weeks for such a team to complete a few minutes’ worth of real work. The typical response to slow progress is to add more and more people to the teams. Just recently we’ve increased our teams sizes but saw that teams that went too large couldn't get very much work done were falling behind schedule. When increasing the team size, team members have even less time to do real work, as they have to help their new colleagues learn the system and the procedures. Making more but smaller teams is the way to go but the architecture we use in this context has to evolve together with the organization. Partitioning a large systems in smaller parts and applying constraints to the communication between the parts of the system is the only way to cope with the decrease of productivity in large teams.
- What execution environment should your microservices applications use? That is, in what kind of environment should they run? Martin Fowler definition of Microservice contains 4 important clues about what Micrservices needs from it’s hosting environment=> Isolation Deployability Leightweight Management Support for diversity These 4 charachteristics are completely covered by Containers One could think that Microservices and Containers are just two faces of the same coin. They are the answer to “how to cope with the constant increase in complexity of IT”
- Every large IT organization I have seen so far in my career has had large project teams that spend almost all their time engaged in communication overhead of one sort or another. It is no exaggeration to say it takes weeks for such a team to complete a few minutes’ worth of real work. The typical response to slow progress is to add more and more people to the teams. Just recently, a client whose teams were already too large to get very much work done were falling behind schedule. Management urgently requested approval to bring contractors on board to speed things up. Now the teams have even less time to do real work, as they have to help their new colleagues learn the system and the procedures. Partitioning a large systems in smaller parts and applying constraints to the communication between the parts of the system is the only way to cope with the decrease of productivity in large teams.
- Standardization of packaging & shipping Running in Isolation Example Install and configure RabbitMQ https://www.rabbitmq.com/install-windows-manual.html Install on shared resource? => Isolation!!!! Install on dedicated VM => Management!!! Resource waste Slow startup Patching
- Container is not just a new technology => complete platform for running & shipping software Platform abstract away a messy problem => docker is a abstraction on shipping software
- The Docker daemon The Docker daemon (dockerd) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services. The Docker client The Docker client (docker) is the primary way that many Docker users interact with Docker. When you use commands such as docker run, the client sends these commands to dockerd, which carries them out. The docker command uses the Docker API. The Docker client can communicate with more than one daemon. Docker registries A Docker registry stores Docker images. Docker Hub and Docker Cloud are public registries that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry. If you use Docker Datacenter (DDC), it includes Docker Trusted Registry (DTR). When you use the docker pull or docker run commands, the required images are pulled from your configured registry. When you use the docker push command, your image is pushed to your configured registry. Docker store allows you to buy and sell Docker images or distribute them for free. For instance, you can buy a Docker image containing an application or service from a software vendor and use the image to deploy the application into your testing, staging, and production environments. You can upgrade the application by pulling the new version of the image and redeploying the containers. Docker objects When you use Docker, you are creating and using images, containers, networks, volumes, plugins, and other objects. This section is a brief overview of some of those objects. IMAGES An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the ubuntu image, but installs the Apache web server and your application, as well as the configuration details needed to make your application run. You might create your own images or you might only use those created by others and published in a registry. To build your own image, you create a Dockerfile with a simple syntax for defining the steps needed to create the image and run it. Each instruction in a Dockerfile creates a layer in the image. When you change the Dockerfile and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization technologies. CONTAINERS A container is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state. By default, a container is relatively well isolated from other containers and its host machine. You can control how isolated a container’s network, storage, or other underlying subsystems are from other containers or from the host machine. A container is defined by its image as well as any configuration options you provide to it when you create or start it. When a container is removed, any changes to its state that are not stored in persistent storage disappear.
- docker ps docker ps -l docker run -it ubuntu bash uname docker image ls ------------------------------------- Indempotence root@483e5c362a7c:/# echo 'hello world!' >> test.txt root@483e5c362a7c:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys test.txt tmp usr var root@483e5c362a7c:/# exit exit PS C:\Users\Geobarteam> docker run -it ubuntu bash root@2e2de01f71f6:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@2e2de01f71f6:/# ---------------------------------------------- Port Mapping PS C:\Users\Geobarteam> docker run -d -p 80:80 nginx c3c6a49d9b0ded5384cfc28d0d779812d6a38a8070aa91da79a71f7d1e8a0353 PS C:\Users\Geobarteam> docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c3c6a49d9b0d nginx "nginx -g 'daemon of…" 38 seconds ago Up 36 seconds 0.0.0.0:80->80/tcp heuristic_yalow -------------------------------- Developing and automation through dockerfile docker build -t merodefields . docker run -d -p 80:80 merodefields ---------------------------------------------- Transfer images through Repository PS C:\Users\Geobarteam> docker tag merodefields geobarteam/merodefields PS C:\Users\Geobarteam> docker push geobarteam/merodefields ---------------------------------------------------- Transfer image to Azure Container Web App Create Resource Web App for Containers ---------------------------------------------- Visual Studio integration Start new project .Net Core docker ------------------------------------------------- Docker compose: https://docs.docker.com/compose/aspnet-mssql-compose/ ----------------------------------------------------