Druva is no stranger to exploring new technologies and pushing the boundaries of traditional computing practices. Just a few years ago, AWS was still in its infancy and cloud computing was beginning to leverage the power of virtual machines (VMs). Both of them are now fully entrenched in the mainstream workplace environment and form the backbone of every major cloud business in the world.
Enter Docker. Not content to sit and watch VMs take over the world, they saw a technology that could be faster, lighter, and more efficient: containerization. Instead of running every application on a separate VM that has its own guest OS, separate CPU threads, and memory resources, Docker simply runs an application with its binaries and libraries directly on its host OS.
This blog describes a small Docker project we’ve been working on to help demonstrate its capabilities. We’ve also included a GitHub link, where you can download and play with the entire thing, end to end.
A Simple Druva inSync Container for Docker Testing
Please note: This container will not allow full-fledged use of or access to a Druva inSync instance. It will, however, provide you with a simple containerized client that you can test using your own Druva inSync instance. Before you conduct this text, you should have a basic understanding of what Docker is and how to run containers. Click here to learn the basics.
Use Case for a Druva inSync Container
There are a lot of advantages to using Docker over standard virtualization. First and foremost, scalability of the solution is astronomical, with exceptionally low overhead and massively reduced infrastructure costs.
Docker goes far beyond efficiency, however. It fundamentally allows for better application development and testing because version control and tracking are applied at an application level and can easily be reverted, with dependencies residing in a single Docker image.
-e INSYNC_USERNAME=”User Name”
Environment Variables and Defaults
Container Setup and Layout
There is no need to configure any specific ports to be opened. The application will open an outbound-only connection to the cloud-based servers. Once this persistent connection is made, backups will be processed as required without any further port openings.
Upon startup, the container will enter the required details into a configuration file which will be written. Once written, the container will then launch the inSync process in a virtual X session to allow the application to function as though it was installed on an ordinary Debian-based desktop operating system.
Optionally, data can be mounted to other locations as desired. The container is set up to run as User: druva, and its home directory is /home/druva. The type of data that is backed up will depend on how the profile has been configured on the Druva console. If you change the default configuration, you may see a “misconfigured backup folder” error message on the console due to the missing directory in the container. Permissions can also cause problems as often known in Docker containers. User druva will likely be running as UID 1000 and GID 1000. If permissions are mapped and/or matched on the local host, this can diminish the potential issues. You can use the following default desktop backup to mount data:
Although many other companies are experimenting with Docker, Druva intends to make it a permanent fixture in our modern delivery chain. Druva has shown that even a large, growing, and highly secure development environment can implement a modern delivery chain like a startup. Docker alone is not the answer, but the ecosystem of supporting tools like Calm.io make Docker more mature and put Druva’s development team in a great position to move from biweekly sprints to continuous delivery and deployment.
For more technical video content, please subscribe to Druva’s YouTube Channel.