Containers and building application images
1. Containers and building application images
Now we discuss containerized applications and how they can be built on Google Cloud. Containers are a preferred method for packaging and deploying your applications. Here's a quick refresher on Containers. Container-based virtualization is an alternative to hardware virtualization, as used in traditional virtual machines. Virtual machines are isolated from one another in part by having each virtual machine have its own instance of the operating system. But operating systems can be slow to boot and can be resource-heavy. Containers respond to these problems by using built-in capabilities of modern operating systems to isolate container environments from one another. A process is a running program. In Linux and Windows, the memory address spaces of running processes have long been isolated from one another. Popular implementations of software containers build on this isolation. They take advantage of additional operating-system features that give processes the capability to have their own namespaces and limit other processes’ access to resources. Containers start much faster than virtual machines and use fewer resources, because each container does not have its own instance of the operating system. Instead, developers configure each container with a minimal set of software libraries to do the job. A lightweight container runtime does the plumbing jobs needed to allow that container to launch and run, calling into the kernel as necessary. The container runtime also determines the image format. Containers can be deployed to both Cloud Run and GKE. So what does a container provide that a virtual machine does not? First, containers provide a clear separation of responsibility. Developers can focus on the application logic and any dependencies that are required for the application. The IT operations teams that will deploy and manage the application don't need to worry about application details like software versions and configurations. Second, containers provide workload portability. Containers are lightweight and can run virtually anywhere, from a developer's laptop to a VM running on-premises or in any cloud. The same application that is tested by a developer on their laptop and tested in an integration environment can run in the production environment. This workload portability simplifies promotion of the app during the development lifecycle and lets you move workloads between clouds and data centers with minimal effort. Third, containers provide application isolation. Containers virtualize CPU, memory, storage, and network resources at the operating system level. Applications are effectively running in their own environments, which lets containerized applications running on the same hardware use different versions of dependencies without affecting each other. By abstracting just the OS instead of the whole virtual computer, a container can "boot" in a fraction of a second. A virtual machine typically takes a minute or more to boot. The container image for your application is a complete package that contains the application binary and all the software required for the application to run. When you deploy the same container image in your development, test, and production environments, your application will perform the same way in each environment. Cloud Build is a fully managed service that lets you set up build pipelines to create a Docker container image for your application and push the image to Artifact Registry. You don't need to download build tools and container images to a build machine or manage your own build infrastructure. By using Artifact Registry and Cloud Build, you can create build pipelines that are automatically triggered when you commit code to a repository. In Cloud Build, you can create a build trigger that is executed based on a trigger type. A trigger type specifies whether a build should be triggered based on commits to a particular branch in a repository or commits that contain a particular tag. You create a build configuration file that specifies the steps in the build pipeline. Steps are analogous to commands or scripts that you execute to build your application. Each build step is a Docker container that's invoked by Cloud Build when the build is executed. The step name identifies the container to invoke for the build step. The images attribute contains the name of the container image to be created by this build configuration. Cloud Build lets you use different code repositories, tag container images to enable searches, and create build steps that perform operations like downloading and processing data. The build configuration can be specified in a YAML or JSON format. Cloud Build mounts your source code into the “/workspace” directory of the Docker container associated with a build step. The artifacts produced by each build step are persisted in the “/workspace” folder and can be used by the following build step. Cloud Build automatically pushes the built container image to Artifact Registry. In Artifact Registry, you can view the status and history of builds for a given container. Cloud Build can also publish build status notifications to Pub/Sub. You can subscribe to these notifications to act based on build status or other attributes.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.