Artifactory is usually promoted as a platform for managing software artifacts. Its core strengths are definitely related to that aspect, mainly:
- Its ability to track the build history of artifacts.
- Its role as the repository of artifacts which will be used as dependencies in downstream builds, and sometimes, released versions used for deployments.
That’s why Artifactory is always identified with the build and release process. An Artifactory instance could be used as a Docker registry also, making it useful from build through deployment even in a container-based environment.
However, at the basic level, Artifactory is a file management system with the option to store metadata about the files being stored. That opens up an opportunity to use Artifactory as a sophisticated file sharing platform for sharing static files across data centers and public cloud regions. Such a use of Artifactory might not be very attractive in a public cloud environment because storage services like AWS S3 could be used to share files between multiple regions.
In a multi-data center environment, file sharing across data centers is not easy to setup. Using the replication feature of Artifactory, a robust file sharing platform that spans multiple data centers could be set up with very little effort. Even public cloud regions could be added to that mix, typically, in a mixed-cloud environment.
Shared File Types
Let's see the file types that are normally needed for DevOps automation tasks which can be shared on an Artifactory based file sharing platform:
Of course, this what Artifactory is known for. The artifacts are normally uploaded to Artifactory as a post-build step on a build management platform such as Jenkins. The artifacts could be uploaded automatically from every build, or from specific builds manually as part of some build and release workflow.
Third-Party Software Artifacts
In Artifactory, files you upload are stored in a local repository. The remote repositories are used to cache artifacts that are actually maintained at a remote location. The best example is that of pointing to a yum repository. A virtual repository is an aggregation of other repositories of the same type. A well configured virtual repository consisting of multiple local and remote repositories can help with caching artifacts related to third-party software as needed. The third-party tools may have to be cached locally for two main reasons:
- Availability: You may not be able to locate a specific version of a third-party tool as it might not exist anymore.
- Restricted Access to the Internet: In such a scenario, the artifact should be uploaded to a local repository; a remote repository configuration will not work.
In my experience, downloading the artifacts from vendor sites and uploading to a local Artifactory repository is simpler and more convenient. Replication of repositories is also easier when they are local.
If you have multiple runtime environments with customizations, the related configuration files might not be part of the build for various reasons, but managing those along with the related build artifacts would make sense when it comes to deployments. Such files should be available in all the data centers where the application needs to be deployed.
Database Backups and Directory Snapshots
In a production environment, application related backups, especially database backups, are taken and managed using specialized systems meant for that. Backups related to DevOps infrastructure might not be part of such efforts and a replicated Artifactory platform could be used for managing smaller backups. The database dumps copies of app directories, et cetera that are automatically taken and stored in Artifactory. These could be the main sources for a DR process for restoring related applications in an unaffected data center.
Besides use in DR, these backups could be used for creating application environments automatically. For example, by restoring the application directories and database from snapshots of related resources from a working instance of an application, a non-production instance could be set up quickly for testing, without having to go through a standard deployment process.
Advantages of Artifactory
- Artifactory is already in place for managing build artifacts. Piggy-backing it to manage the rest of the files is easy, and there is no need to bring in another service like S3, even if you are entirely on public cloud.
- It is an excellent UI for casual users of the file sharing platform. Users who may want to download certain files manually can do it easily with no training.
- For DevOps automation projects, using Artifactory REST API to upload/download files is easy.
Data Center Awareness
One of the main uses of a replicated file sharing platform is making deployment related files available in the same data center where the deployment is done. It could be implemented in couple of ways:
- By Configuring DNS: Using network routing techniques such as Anycast or GeoLocation, it could be possible to route the domain/CNAME of the file sharing hub to a specific instance of Artifactory. A DNS-based solution would be simpler to use, as the file sharing hub could be referenced by the same CNAME in all the data center environments.
- By Using a CM System: The file sharing hub location can be referenced by a global variable in configuration management (CM) systems like Ansible. For example, in Ansible, pass the data center name as a parameter to the deployment playbook. Based on that, the playbook can pick the related Artifactory instance to use from the global settings.
An Artifactory-based infrastructure that is replicated in each data center, with one source-of-truth instance, is simple to setup and solves the issues related to distributing various types of files that are needed for deployments and DevOps automation projects in a multi-data center environment. Its user interface and REST API support are more suitable for a highly automated environment, and it is a superior solution compared to any custom solutions based on NFS or cloud storage services.