Special thanks to Chris Vignola, co-author of this article.
The September 2015 Liberty Beta includes a preview of management function for Liberty Docker containers. A Liberty Docker container is a Liberty Server packaged and deployed through a Docker image. New in this beta is collective management for these containers. This is a continuation of Libertyâ€™s embrace of Docker, which started with the publishing of a Liberty Docker image on Docker Hub.
The management functions for Liberty Docker containers in this beta include: collective registration, Admin Center visualization and operations, and phase 1 auto-scaling. Collective registration is simply the use of the
collective join command to add a Liberty Docker container to a collective for management. Once a member of a collective, the Liberty Docker container is visible in the Admin Center. Status, start, and stop operations are available. Finally, you can configure the image to be scalable, using Libertyâ€™s scaling controller feature. â€śPhase 1â€ť simply means the beta auto-scaling function is limited to a subset of the full auto-scaling capability regular Liberty servers enjoy.
The following diagram depicts the workflow for building, publishing, and deploying Liberty Docker images to a collective and creating containers
- Start by using your favorite developer tools to create your application on a Liberty server. Package and publish your app and its dependencies as a Docker image. Detailed instructions are located at the Beta Knowledge Center, including an example Dockerfile.
Pull your Docker image to a Docker Host (i.e. a system that has the Docker engine running) and create a Liberty container.
Join the Liberty container to the collective and bang! You can view and control your Liberty container through the Liberty Admin Center. The scripts you need to join and remove a Liberty server from the container are:
memberHost="$(hostname -i)" /opt/ibm/wlp/bin/collective join defaultServer --host=$controllerHost --port=$controllerPort --user=$controllerUser --password=$controllerPassword --hostName=$memberHost --createConfigFile --keystorePassword=$memberKeystorePassword --containerName=$containerName --containerHost=$containerHost --autoAcceptCertificates mkdir /opt/ibm/wlp/usr/servers/defaultServer/configDropins mkdir /opt/ibm/wlp/usr/servers/defaultServer/configDropins/overrides mv /opt/ibm/wlp/usr/servers/defaultServer/c*.xml /opt/ibm/wlp/usr/servers/defaultServer/configDropins/overrides rm /opt/ibm/docker/env.properties echo containerName=$containerName > /opt/ibm/docker/env.properties echo containerHost=$containerHost >> /opt/ibm/docker/env.properties echo memberHttpPort=$memberHttpPort >> /opt/ibm/docker/env.properties echo memberHttpsPort=$memberHttpsPort >> /opt/ibm/docker/env.properties
memberHost="$(hostname -i)" /opt/ibm/wlp/bin/collective remove defaultServer --host=$controllerHost --port=$controllerPort --user=$controllerUser --password=$controllerPassword --hostName=$memberHost --containerName=$containerName --autoAcceptCertificates
Optionally, you can configure Liberty auto-scaling to scale out your Liberty Docker image. In this beta, only the scaling policy min and max settings control the number of containers for a given image. The
removescripts you used in Step 3 must be placed at
/opt/ibm/dockerin the Docker image and named
removeMember. The Beta Knowledge Center contains an example
server.xmlfor the Liberty server within the container.
You can see all this in motion in the following video:
You might be wondering what this support will look like once it is generally available. While we canâ€™t make any promises, obvious improvements would include remote deployment, phase 2 auto-scaling (i.e. metrics-based, like CPU), health management, and analytics integration.
So if managing Liberty Docker containers interests you, stay tuned and watch for what comes next!