CNFs are becoming the dominant way to deploy traditional telecommunications functions. In Anatomy of a CNF - Part 1 and Part 2 of this series, we discussed the term CNF and the key subcomponent of a CNF, the container image. Now that we have addressed a container image let's continue the conversation by asking, "Where do I put the container image after it is built?"
A key reason for building a container image is to deploy it. Just like a web page needs a web server to store the information it displays, a container image needs a container registry to keep the image and be available for others to download and deploy. In addition, just like a web page, the container registry needs to be able to do security to ensure that no one has tampered with the images. Also, the container registry provides a way to limit who may download a specific image.
Three Types of Container Registries
I like to define three types of container registries. The first type of registry is a public registry. There are many public registries on the Internet, but one of the oldest and most common is Docker Hub. Docker Hub is the default registry for Docker and Kubernetes, and it stores many publicly available images.
The second type of registry is a public registry with permissions. The permissions are essential to access the container images even though they are on the public Internet. Technically, Docker Hub can fall into this category, but a better example is Jfrog. Jfrog provides a service in which developers or users of images can store images with extra permission-based protection.
A private registry is the third type of container registry deployed inside an enterprise's firewall. We focus on the telecom industry and CNFs, so we should consider a private registry as software deployed inside the operator's telco network. One example of open-source software designed to be a private registry is Harbor. If you deploy a private registry like Harbor, you must provide the server, deploy the software, and maintain the system. Of course, you have additional security since it is inside your firewall, but now it's your responsibility.
From our Anatomy of a CNF perspective, one key element is where we store the container images. From an end-to-end perspective, a vendor creates a CNF, and that CNF is composed of several container images and more that we will address later in the series. A vendor needs to store their images in a registry available to the operator, which may be a public registry with appropriate permissions, or they push the images to an operator's registry. The operator’s network typically has at least two registry types. The first is a registry connected to the vendor, and the second connects to a test network. After the operator undergoes a series of CNF tests, the container images push to a production registry, where an operator deploys the CNF to the production network.
To support a CNF, one must deploy other resources, as we discussed only the container image. We've now looked at where the image is stored to prepare it for deployment.
Part 4 of Anatomy of a CNF explores other deployable resources needed to support a CNF.
Chris Reece, Technologist, Award Solutions, Inc.
Chris Reece works with leading global service providers, transforming networks and empowering individuals in 5G, Virtualization/Containerization, and Machine Learning/Artificial Intelligence. Service providers rely on Chris to paint both the big picture and the business impact of technology and appreciate his enthusiasm for getting into deep, detailed discussions when needed. You may have seen Chris on Award Solutions' YouTube Channel. In addition, Chris is featured at leading telecom conferences worldwide, including MWC, and in publications like IEEE Spectrum and DZONE.
Chris holds a master's degree in Computer Science Telecommunications from the University of Missouri at Kansas City and a bachelor's degree in Computer Science and Mathematics from Cameron University. He also holds four patents in wireless technologies.