Even the best software application that works seamlessly in the development server, may go haywire in the live server, due to version mismatch or compatibility issues with the server software. To facilitate smooth completion of a software project, its development and production server environments have to be maintained alike. But setting up these environments for each project is a tedious and time-consuming process.
For fast deployment of identical project environments, a container virtualization technology can be used. A container is a virtual environment that hosts all the project-related applications, services and tools in a single entity. Using custom templates, it is possible to effortlessly emulate the same environment in different containers.
Our solution to speed up project delivery
With our DevOps service plan, Bobcares helps businesses deliver projects on time. Recently we were contacted by a software development company who wanted an affordable and easy-to-deploy solution to reduce project delays. The projects were hosted on dedicated servers, and considerable time was lost in setting up the environments.
To speed up project delivery, we implemented a solution using OpenVZ, an open source server virtualization technology. Using OpenVZ, multiple secure containers (aka VEs) can be deployed on a single Linux server. Each container can be rebooted independently and can have its own IP addresses, memory, applications, system libraries and configuration files.
OpenVZ was installed and configured in CentOS servers. As each project required a different set of applications and tools, we configured container templates for development and production environments at the the start of each project. Using these templates, containers were quickly deployed in the OpenVZ server.
Here is the design of our container virtualization solution, and a walk-through of how we implemented it.
Server virtualization using OpenVZ containers
1. Installing OpenVZ and its utilities
After installing CentOS in the server, we configured the yum repository for OpenVZ package. Then the package installation process was completed.
[root@OpenVZ ~]# wget -P /etc/yum.repos.d/ http://ftp.openvz.org/openvz.repo [root@OpenVZ ~]# rpm --import http://ftp.openvz.org/RPM-GPG-Key-OpenVZ [root@OpenVZ ~]# yum install vzkernel Installed: vzkernel.x86_64 0:2.6.32-042stab113.11 [root@OpenVZ ~]# yum install vzctl vzquota ploop Installed: ploop.x86_64 0:1.14.1-1 vzctl.x86_64 0:4.9.4-1 vzquota.x86_64 0:3.1-1
2. Configuration settings in the server
a. SELinux had to be disabled in server as it was not compatible with OpenVZ. For this, we set “SELINUX=disabled” in the config file /etc/sysconfig/selinux.
b. We then configured /etc/sysctl.conf with the settings needed for OpenVZ.
# Controls IP packet forwarding net.ipv4.ip_forward = 1 net.ipv6.conf.default.forwarding = 1 net.ipv6.conf.all.forwarding = 1 net.ipv4.conf.default.proxy_arp = 0 # Controls source route verification net.ipv4.conf.default.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Controls the System Request debugging functionality of the kernel kernel.sysrq = 1 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0
c. We edited ” /boot/grub/menu.lst ” and set OpenVZ as the default boot image.
grub.conf generated by anaconda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title OpenVZ (2.6.32-042stab113.11) root (hd0,0) kernel /vmlinuz-2.6.32-042stab113.11 ro root=/dev/mapper/VolGroup-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-042stab113.11.img
3. Creating OpenVZ containers
The server was rebooted and service ‘vz’ was enabled in chkconfig. Our OpenVZ server was ready. Containers were then created in the server for different purposes.
[root@OpenVZ ~]# vzlist -a CTID NPROC STATUS IP_ADDR HOSTNAME 102 131 running XX.XXX.XXX.XX server1.openvz.com 103 124 running XX.XXX.XXX.XX server2.openvz.com 105 - stopped XX.XXX.XXX.XX server3.openvz.com
4. Container templates for fast deployment
We configured and maintained templates for each project. Using these templates, we quickly deployed containers to maintain identical environments for development, testing and production. When one project got over, these containers were destroyed to free up resources for the next project. Reusing the containers helped the customer to achieve considerable cost-benefit too.
Our container-based virtualization solution helped to reduce project turn-around time for the company. Automated provisioning using our custom templates spared customer from the overhead of setting up project environments. Our 24/7 support team monitored and managed this environment, which enabled the development team to work seamlessly and to deliver projects on time.
Bobcares helps software businesses manage their DevOps and save time through virtualization setup, configuration management and code pipeline automation, as a part of our DevOps services.
Hi,
How are you handling your backups?
Hi Ashley,
There’s no single tool that we recommend for any situation. In the case discussed here, we used a combination of
vzdump,BaculaandXtraBackup. This was needed because the designer hosted some of the websites, and not all sites had the same maintenance plan.Container image backup using vzdump was taken once a day – This was for disaster recovery.
Incremental backup using Bacula was taken for website backups – and even databases in some cases. Details here : https://bobcares.com/blog/how-we-configured-cost-effective-vps-backups-using-bacula/
Critical database backups were taken using Xtrabackup. More details here : https://bobcares.com/blog/how-to-setup-and-maintain-percona-backup-using-xtrabackup/