| copyright | lastupdated | ||
|---|---|---|---|
|
2018-07-19 |
{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}
Learn more about the technology behind {{site.data.keyword.containerlong}}. {:shortdesc}
{: #docker_containers}
Built on existing Linux container technology (LXC), the open source project named Docker defined templates for how to package software into standardized units, called containers, that include all of the elements that an app needs to run. {:shortdesc}
Learn about some basic Docker concepts:
- Image
- A container image is the base for every container that you want to run. Container images are built from a Dockerfile, a text file that defines how to build the image and which build artifacts to include in it, such as the app, the app's configuration, and its dependencies. Images are always built from other images, making them quick to configure. Let someone else do the bulk of the work on an image and then tweak it for your use.
- Registry
- An image registry is a place to store, retrieve, and share container images. Images that are stored in a registry can either be publicly available (public registry) or accessible by a small group of users (private registry). {{site.data.keyword.containershort_notm}} offers public images, such as ibmliberty, that you can use to create your first containerized app. When it comes to enterprise applications, use a private registry like the one that is provided in {{site.data.keyword.Bluemix_notm}} to protect your images from being used by unauthorized users.
- Container
- Every container is created from an image. A container is a packaged app with all of its dependencies so that the app can be moved between environments and run without changes. Unlike virtual machines, containers do not virtualize a device, its operating system, and the underlying hardware. Only the app code, run time, system tools, libraries, and settings are packaged inside the container. Containers run as isolated processes on Ubuntu compute hosts and share the host operating system and its hardware resources. This approach makes a container more lightweight, portable, and efficient than a virtual machine.
{: #container_benefits}
- Containers are agile
- Containers simplify system administration by providing standardized environments for development and production deployments. The lightweight run time enables rapid scale-up and scale-down of deployments. Remove the complexity of managing different operating system platforms and their underlying infrastructures by using containers to help you deploy and run any app on any infrastructure quickly and reliably.
- Containers are small
- You can fit many containers in the amount of space that a single virtual machine requires.
- Containers are portable
-
- Reuse pieces of images to build containers.
- Move app code quickly from staging to production environments.
- Automate your processes with continuous delivery tools.
Learn more about [securing your personal information](cs_secure.html#pi) when you work with container images.
Ready to gain deeper knowledge of Docker? Learn how Docker and {{site.data.keyword.containershort_notm}} work together by completing this course.
{: #kubernetes_basics}
The open source project named Kubernetes combines running a containerized infrastructure with production work loads, open source contributions, and Docker container management tools. The Kubernetes infrastructure provides an isolated and secure app platform for managing containers that is portable, extensible, and self-healing in case of failovers.
{:shortdesc}
Learn about some basic Kubernetes concepts as shown in the following diagram.
- Account
- Your account refers to your {{site.data.keyword.Bluemix_notm}} account.
- Cluster
- A Kubernetes cluster consists of one or more compute hosts that are called worker nodes. Worker nodes are managed by a Kubernetes master that centrally controls and monitors all Kubernetes resources in the cluster. So when you deploy the resources for a containerized app, the Kubernetes master decides which worker node to deploy those resources on, taking into account the deployment requirements and available capacity in the cluster. Kubernetes resources include services, deployments, and pods.
- Service
- A service is a Kubernetes resource that groups a set of pods and provides network connectivity to these pods without exposing the actual private IP address of each pod. You can use a service to make your app available within your cluster or to the public internet.
- Deployment
- A deployment is a Kubernetes resource where you might specify information about other resources or capabilities that are required to run your app, such as services, persistent storage, or annotations. You document a deployment in a configuration YAML file, and then apply it to the cluster. The Kubernetes master configures the resources and deploys containers into pods on the worker nodes with available capacity.
Define update strategies for your app, including the number of pods that you want to add during a rolling update and the number of pods that can be unavailable at a time. When you perform a rolling update, the deployment checks whether the update is working and stops the rollout when failures are detected. - Pod
- Every containerized app that is deployed into a cluster is deployed, run, and managed by a Kubernetes resource that is called a pod. Pods represent small deployable units in a Kubernetes cluster and are used to group the containers that must be treated as a single unit. In most cases, each container is deployed in its own pod. However, an app might require a container and other helper containers to be deployed into one pod so that those containers can be addressed by using the same private IP address.
- App
- An app might refer to a complete app or a component of an app. You might deploy components of an app in separate pods or separate worker nodes.
Learn more about [securing your personal information](cs_secure.html#pi) when you work with Kubernetes resources.
Ready to gain deeper knowledge of Kubernetes?
{: #architecture}
In a Kubernetes cluster that runs on {{site.data.keyword.containershort_notm}}, your containerized apps are hosted on compute hosts that are called worker nodes. Well, to be more specific, the apps run in pods and the pods are hosted on worker nodes. Worker nodes are managed by the Kubernetes master. The Kubernetes master and the worker nodes communicate with each other through secure TLS certificates and an openVPN connection to orchestrate your cluster configurations. {: shortdesc}
What's the difference between the Kubernetes master and a worker node? Glad you asked.
- Kubernetes master
- The Kubernetes master is tasked with managing all compute, network, and storage resources in the cluster. The Kubernetes master ensures that your containerized apps and services are equally deployed to the worker nodes in the cluster. Depending on how you configure your app and services the master determines the worker node that has sufficient resources to fulfill the app's requirements.
- Worker node
- Each worker node is a physical machine (bare metal) or a virtual machine that runs on physical hardware in the cloud environment. When you provision a worker node, you determine the resources that are available to the containers that are hosted on that worker node. Out of the box, your worker nodes are set up with an {{site.data.keyword.IBM_notm}} managed Docker Engine, separate compute resources, networking, and a volume service. The built-in security features provide isolation, resource management capabilities, and worker node security compliance.
Want to see how {{site.data.keyword.containerlong_notm}} can be used with other products and services? Check out some of the integrations.