There are two buzzwords that we have heard in the IT world for some time now: Cloud and Containerization. For me, 2016 proved that these two topics have changed from hype to reality, even in the biggest enterprises, and a lot of customers were asking for our solutions, like OpenText™ InfoArchive, in public clouds and/or running as Docker containers. While our engineering and PS teams are doing a great job in providing these solutions, I decided to walk this route myself. Follow me on the journey if you’re interested.
I started my tests by creating a Docker hub account. The account private repository will be used to store the InfoArchive Docker images and automatically deploy from there. It is very easy to create a Docker container from InfoArchive – talk to me if you want to know more. It takes just a couple of steps and you’ll have your InfoArchive Docker container image ready. What’s next? Now let’s run this image in Amazon EC2 Container Services (ECS).
Welcome to the “cloud world”
If you’re new to the Amazon world you might have difficulty understanding some of the terminology around Amazon ECS. I hope this post will help you with this.
In the first step we need an ECS Cluster. ECS Cluster of EC2 instances and services. EC2 instances are our “good old” virtual machines and represent our available compute resources. The work that you assign to the cluster is described as “services”. The picture below shows that our InfoArchive cluster started with 3 micro servers (each of them automatically initiated by ECS from the below amzn-ami… VM image):
Within a minute your cluster compute resources are running and waiting for you to assign them some work. Ignore the memory values in the below screenshot – I took the screenshot with 3 running tasks occupying the memory already.
InfoArchive is a “classic” three-tiered architecture product: Native XML database xDB at the backend, InfoArchive server as middleware and InfoArchive web UI. To prepare for scalability requirements of our deployment we’ll run each of the tiers as dedicated containers. We’ll “front-end” each of the tiers with an EC2 load balancer. This approach will also simplify the configuration of the container instances, since each container instance will have to connect to the underlying load balancer only (with known static hostname/IP) instead of trying to connect with the constantly changing IP addresses of the container instances. On a very high level the architecture can be depicted as shown below:
EC2 load balancers are set up quickly – my list (shown below) contains 4 instances since I’ve also configured a dedicated public load balancer for xDB connectivity.
With this step completed the ECS cluster, its compute resources and the cluster load balancers are prepared. Let’s put InfoArchive on the cluster now.