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.
Example Usage
docker create
-e INSYNC_TOKEN=”xxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
-e INSYNC_MAIL=”user@domain.org”
-e INSYNC_USERNAME=”User Name”
-e INSYNC_STORAGE=”us-east-1″
-e INSYNC_PROFILE=”Default”
–name=insync
1activegeek/druva_insync
Environment Variables and Defaults
-e INSYNC_ADDRESS=”cloud.druva.com”
-e INSYNC_PORT=”443″
-e INSYNC_STORAGE=””
-e INSYNC_PROFILE=””
-e INSYNC_USERNAME=””
-e INSYNC_MAIL=””
-e INSYNC_TOKEN=””
-e INSYNC_DOWNLOAD=”https://downloads.druva.com/downloads/inSync/Linux/5.9/druva-insync-client_5.9-51251_amd64.deb”
-e USER=”druva”
-e HOME=”/home/druva/”
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:
-v /local/path:/home/druva/Desktop
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 is 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.
