IBM Bluemix Experience: Containers advanced

The previous article described the containers service for Bluemix and how to use a custom Docker image to create a container instance and provide services to the outside world. In addition to custom mirroring, Bluemix containers can also use the image on the Docker hub to create container instances, provided that the images must be public.

The Bluemix CLI can complete the task of replicating mirroring from the Docker hub.

sudo CF IC CPI Tomcat:7 registry.ng.bluemix.net/htcn_us_south_1/tomcat:7

After executing the above command, copy the image of a Tomcat 7 from the Docker hub to the private repository of Bluemix. The URL format for logging in to Bluemix and private repository using "CF ICS" is not covered here, please refer to the previous article for details.

When the mirror copy is complete, you can see it in the Web console and use the copied image to create a new container instance.

High availability in the production environment is essential. Bluemix's containers service provides scalable group functionality to enable highly available deployments of Docker containers.

On the page where you created the new container instance, select Scalable tab and start creating the scalable group.

Note the "HTTP port" field, where only the port number exposed in the image is filled in, i.e. the port number expose in Dockerfile. For example: The port number for the default expose in the Tomcat image is 8080, so you need to fill in HTTP port with "8080".

The host field specifies a public domain name to access the scalable group, where we specify the full domain name: "hunter-demo-1.mybluemix.net". Of course, this domain name must be global (globally) unique (this way is a bit like Microsoft Azure's cloud service). The public domain name is followed by a load balancer (Gorouter, a reverse proxy that supports load balancing) to distribute access traffic to each container instance within the scalable group. This load balancer looks simple, but forwards the front-end traffic to the backend in the form of polling. There is no session hold, and there is no port mapping. A more distinctive feature is that an SSL certificate is bound by default on the Load Balancer instance, and the HTTPS protocol can be used directly to access the application deployed in the container instance without the need for the app itself to support the HTTPS protocol! This feature makes it easy for applications to support the HTTPS protocol without the need for complex configuration on the Web server. The user uses HTTPS protocol communication between the load balancer and the load Balancer to use the HTTP protocol between the application instances.

Once the scalable group is created, the host domain name provides access to the applications deployed in the container.

Next, create the auto-scaling policy for scalable Group:

You can define container instance scaling rules based on CPU and memory two metrics.

Includes specifying the maximum number of container instances to run in the current scalable group and the minimum number of container instances.

The instances in the scalable group support the auto-recovery feature. The "Health Monitor" component of the Bluemix Containers Service detects HTTP servers in each container instance every 90 seconds, and if a container instance fails for 2 successive probes, the container instance is automatically destroyed and rebuilt.

A scalable group must contain at least 2 container instances in order to ensure high availability. With the "Auto discovery" feature, personal experience suggests a minimum of 3 container instances in a scalable group.

IBM Bluemix Experience: Containers advanced