There are many different ways of deploying code, TAA have requested an investigation to see if containers can make their solution more portable and easier to manage.
- Releasing
- Deploying
- Monitoring
This challenge introduces containers - which enable easily reproducible environments, perfect for deploying microservices. Azure DevOps has extensive support for building and releasing containers.
The first step in containerising your application is to build your code into a deployable image that is then used to instantiate a container. Build each of the services into individual Docker images then test each service within a container on your development machine.
- Refer to the helpful resources for example Dockerfiles
- Pass settings using environment variables
Now that the containers are successfully running locally, update the Azure DevOps Build Pipeline to build container images of your services. Instead of deploying a release artifact deploy these images into an Azure Container Registry (ACR).
- Create a single Azure Container Registry resource, this can make it easier to ensure the image is the same across environments
- Ensure you tag your containers when you release them to ACR. Azure DevOps exposes variables when building that may make good candidates.
- Azure Container Registry Documentation
- Build and Push to Azure Container Registry
- Azure Container Registry
Now the container images are stored in a container registry and are ready to be deployed, update the Release Pipelines to deploy the images into multiple Azure Web App for Containers services in your test and production environments.
- You can manually deploy the Web App for Containers resources manually and use Azure DevOps to push the containers. Bonus points if you update your ARM template first.
Setting up an entire environment can be challenging. Docker Compose enables developers to design multi-container applications easily while ensuring that the application can be tested easily.
Make a Docker Compose file that starts all the services and runs them locally.
- Pass settings using environment variables from the host to reduce the amount of container changes.
- You may need to trust new self-signed SSL certificates or pass them through from the host.
There is another benefit in defining how containers work together using an orchestrator such as Docker Compose. Some containers are built only to support the primary application and make sense to be treated as a single unit within the same lifecycle. These containers commonly proxy traffic, log requests or provide authentication to a specific service. It is possible to expose only the services you need to the public and manage the lifecycle of those containers together while still keeping your microservices decoupled and isolated from each other.
Bundle the frontend web app and all backend services into one Docker Compose file and release it to a multi-container Web App using Azure DevOps. Only expose the frontend website to public internet traffic.
- Pass settings using environment variables from the host to reduce the amount of container changes.
- Deploy the Identity Service separately.