DevOps Engineer and Developer in Calgary, AB, Canada

We were getting issues when using a proprietary P2V tool on some outdated versions of Linux operating systems running on old hardware, Sun Fire v240. It turned out that this kind of hardware doesn't support the tool. However, the P2V project had a tight timeline, and my client needed to finish it as planned.

Given my long-term experience with open-source software, I chose Clonezilla for this activity. Due to the old hardware on which Linux instances were running on, I had to customize Clonezilla by adding specific storage and network kernel modules to read data from disks and transfer them through the LAN. After this, the P2V was a quite simple two-step process:

• Creating an image of all physical disks on the Sun Fire v240 on the bare-metal server and copying it to network-attached storage (NAS) over the network. Clonezilla was loaded on the Sun Fire v240 as an image via ALOM.
• Restoring the image on an empty VM. This VM needed a disk layout similar to the bare-metal server. Clonezilla was loaded on VMware as a media drive.

The custom P2V process had to be done for 10 more Sun Fire v240 servers.

A client struggled with network devices whose IP address changed over time, making firewall rules break. The firewall vendor (Cisco) didn't have a specific tool for this scenario. Since the client had thousands of devices attached to the network across different locations, they needed a custom solution.

I developed this custom solution using the vendor's Firewall API and Python to process the data. These scripts ran as a Docker container on Red Hat OpenShift. The custom software consisted of the following:

• One Python process that downloaded the data from the vendor's management console via a REST API in JSON format.
• Another Python process that processed the data provided IP address parameters.
• A separate Python script built daily reports.

As the amount of data downloaded via an API was massive—around 1.5TB—and the downloading process took a long time, it had to be run as a scheduled job once a day. The expected outcome was a daily JSON report containing a list of network devices and the associated firewall rules given the IP address parameters. This report lets the client know what firewall rules are outdated, which devices change IP addresses, and how often.

Automated the provisioning of over 100 ephemeral development and testing environments for an on-premise app primarily handled by hand. I needed the following to set up an environment:

• Virtual machines running on VMWare vSphere.
• Each virtual machine had to be set up on Red Hat Satellite for package management and operating system patching.
• Subnets and static IP addresses were managed by Men&Mice as IP Address Management (IPAM) software.
• Active Directory (AD) as identity management software.

Ansible and Ansible Tower were chosen to automate and orchestrate all this to follow industry standards. As a result, I wrote modular Ansible playbooks to connect to:

• Men&Mice via a REST API to create new subnets if necessary and get the available IP address(es) for virtual machines to be built.
• vSphere via a REST API to create virtual machines with CPU, memory, storage, and network specifications from YAML files.
• Red Hat Satellite via a REST API to create a profile for the new virtual machine, so it receives operating system patches and software packages.
• AD via an LDAP client to add the virtual machine to the proper domain.

Ansible Tower orchestrated the process through a pipeline with multiple stages and access control.

The client needed CI/CD pipelines to build and deploy Node.js apps running as Docker containers. I did the following to achieve this automation:

• Used a Bitbucket Pipeline to build and deploy it straight to non-production environments, such as testing and staging. The build stage builds a Docker image, tags it with a semantic versioning commit tag and commit ID, and pushes it to JFrog Artifactory, a default Docker repository. The second stage of the pipeline deploys this image to AWS ECS via Bitbucket Pipelines by setting up a new task definition that functions only if the image version has changed.
• Handled deployments to production through a Jenkins job that connects to AWS ECS and follows the same process, i.e., it creates a new task definition only if a different image version is deployed. This Jenkins job displays a drop-down feature of the available image versions on Jfrog. These versions are taken on the fly via a JFrog REST API. The app versions shown here are the ones that were promoted after the image had been tested and approved for production.

This Jenkins job is helpful for manual app rollbacks and/or regular manual redeployments.