Depending on the cloud provider, there are different ways to develop an image. An image is a single file with a complete copy of the structure and contents of the file system of a data carrier. Software distributions, such as operating system distributions or disks with pre-installed products, can be distributed via images.
In our blog post: "How to create an image on a Cloud Marketplace?" there are step-by-step instructions on how to create a cloud image.
After creating such an image, developers often face a tedious manual process in order to test the created code.
But wouldn't it be much better to deploy and then test an image with just one click?
The third part of the blog series on cloud marketplaces is dedicated to the topic: "How to test an image created in the cloud?".
To move from long and tedious process in which developers manually do the testing of their code, a CI/CD pipeline can be used in order to have a more robust and reliable testing process. The idea is that developers should be able to deploy and test images with just one click of a button. To accomplish that, Gitlab CI/CD, Packer, Terraform and shell scripts can be used. With Packer, an image can be built and hosted on some Cloud provider, Terraform then takes the built image and deploys a virtual machine with that image. With the virtual machine running, testing scripts (checking if specific port is open, checking if login works, testing the actual functionalities of the product etc.) can be run. After the testing scripts are done, Terraform destroys all the resources created in the Cloud provider that were provisioned during testing.
Step 1: Developer commits code
Step 2: Building image with Packer is triggered
Step 3: Packer builds image and returns image id (e.g id = xyz)
Step 4: Launch VM with image id = xyz
Step 5: Terraform launches VM and returns IP address of that VM
Step 6: Test VM with IP from step 5
Step 7: Test results stored
Step 8: Destroy test VM
Step 9: Test VM destroyed
Without GitLab CI/CD, developers would first manually build an image for Cloud using Packer. Once the image is created and hosted on some cloud provider, the developer would proceed to create a virtual machine based on the image created. The process of creating VM was usually done from the Cloud provider's console. After the virtual machine was created, the developer would then manually test the image, for example,by checking if the website is accessible from the browser, if login page is accessible, the actual functionality of the product and so on.
With GitLab CI/CD all this process can be automated. GitLab CI/CD orchestrates all the communication between Packer, Terraform and testing scripts and ensures the proper order of execution.
Once developer commits to GitLab repository, Packer starts building the desired image. Once the image building process is done, the image is hosted on some Cloud provider. Every image has its own unique ID. It is important that the ID of some particular is known to GitLab CI/CD because with that image ID, the next step can be taken – launching a virtual machine with that image ID using Terraform.
Terraform receives the image ID from the previous step as an input. Developers already have a Terraform configuration for launching virtual machines (this is some kind of template which tells Terraform what kind of virtual machine to run). In Terraform the configuration is written where to launch the virtual machine (which network, subnet etc.) and what kind of machine to launch (how many CPU cores, disk space, GB of RAM etc.).
There’s also a parameter for image ID, and this image ID is coming from Packer. Based on all this information (network, subnet, disk space, number of CPU cores and image ID) Terraform can launch this specific VM. Once the machine is launched, the IP address of that machine is known to GitLab CI/CD because with that IP address, the next step can be done such as testing the VM.
In order to test the VM, among other things, testing scripts should know the IP address of the machine that’s being tested. Using shell scripts we can check the connectivity to the instance provisioned by Terraform and most importantly we can check the actual functionalities of the image that we built.
Would you like to learn more about the cloud? Then feel free to visit our corresponding blog category.
At Libelle IT Group, we also rely on the advantages of the cloud and provide you with various solutions. Use the cloud editions of Libelle DataMasking (AWS / Microsoft Azure), Libelle SystemCopy (AWS / Microsoft Azure) or Libelle CloudShadow (IBM Cloud) now.