This course is designed to give you a solid understanding of containers and how they are used in Azure DevOps. It begins by looking at creating deployable images through Docker containers, microservices, and at the various container-related services available in Azure, including Azure Container Instances, the Azure Kubernetes Service, the Azure Container Registry, Azure Service Fabric, and Azure App Service.
The course also looks at Dockerfile and Docker multi-stage builds before finishing with a hands-on demonstration that shows you how to create an Azure Container Registry.
For any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Learn about Docker and its role in deploying containerized apps
- Understand how microservices can be used for deploying apps
- Learn about the container-related services available in Azure
- Learn about using multi-stage builds when working with Docker
- Gain a practical understanding of how to create an Azure Container Registry
- Gain a practical understanding of how to add Docker support to an application
This course is intended for DevOps professionals who wish to learn how to use containers to design and implement strategies for developing application code and infrastructure that allow for continuous integration, testing, delivery, monitoring, and feedback.
To get the most from this course, you should have a basic understanding of the Azure platform and of container concepts.
Hi there. Welcome to Best Practices for Multi-Stage Builds. In this lecture, we’re going to review some of the best practices that you should be following when working with multi-stage builds. We’re going to talk about adopting container modularity, avoiding unnecessary packages, choosing an appropriate base, and avoiding the inclusion of application data.
When working with builds, you really want to avoid overly complex container images that couple together several applications. Instead, what you should be doing is using multiple containers, with each one intended for a single purpose. For example, you might want to put a website in one container but relegate the database for the website to another container.
While there are always going to be exceptions to this rule, splitting up the components of an application into separate containers makes it more likely that you will be able to minimize work effort by being able to reuse containers. Adopting container modularity will also often make it easier to scale an application. Using our website example from earlier, container modularity would allow you to add replicas of the website container while leaving the database container alone.
An easy way to minimize image sizes is to avoid including unnecessary packages in your images. For example, instead of including packages that you think you MIGHT need, leave them out until you are sure you need them. Once you are sure you need them, you can include them.
Choosing an appropriate base image, or parent image, allows you to optimize the contents of your Dockerfile. By starting with an image that only contains the packages that you need, you can keep your Dockerfiles in check.
Although it’s possible to store your application data right inside the container, doing so increases the size of your image. This runs counter to the idea of optimizing things. Instead of storing app data in your containers, you should consider using docker volume support. By doing so, you can maintain isolation of the application itself, and its data.
For more Dockerfile best practices, visit the URL that you see on your screen:
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.