Deploy ACR apps in ACI as a group - Azure Tutorial

- [Instructor] To run my application in Azure Container Instance, I only need to write one line in Azure CLI script. The Azure CLI command to use is aides at container create. As parameters, the command simply takes a reference to the container image repository, the DNS label for the fully qualified domain name and required network ports to be exposed from the container. If the container image is in a public repository, such as Docker Hub, only path to the image is required. To create a container instance resource from a private container registry, such as Azure Container Registry, you need to provide authentication details, not just the image name and path. In AZ CLI, you can define the service principle ID and password by defining the registry login server, registry username, and registry password parameters. If you work on the container-create command from an Azure service, such as a virtual machine, you could authenticate to the container registry using a managed identity. Azure Portal, however, only supports authenticating to Azure Container Registry using the legacy admin account. As an optional parameter, you can define the CPU account and the memory allocation or other advanced features in the same command. To run the command, I'm going to right-click and select Run Line in Terminal. Once we run the command, it takes a few seconds for the container network resource to be created and the image to be pulled. Once that is complete, we can navigate to the application. Once our application is created as a container instance, we then copy the fully-qualified domain name and navigate to the website. The deployment unit in Azure Container Instance is a container group. A container group can hold one or more container images. Containers in a container group should follow the same lifecycle. They share resources, such as environmental variables, storage volumes, secrets and network configurations. It makes sense to put your application in a container group and separate certain deployment parts, such as back end and front end, so that they can be developed and built in a different pace. Another frequent use case for container groups would be to build a separate monitoring application that will monitor the actual application's health. This type of a deployment pattern is called a sidecar. Another use case for a sidecar pattern will be to create a separate log-collector application, which would collect logs and metrics from the main application and store those logs in a persistent, long-term storage. A container group is exposed to a single, public IP address. In order to communicate to the outside world, containers need to expose their ports. Container group then maps those ports into publicly-accessible ports. Inside the container group, container instances can reach each other to a local host, as they are hosted in the same note. If the containers do not trust each other, they should not be placed in the same container group.