Tips and Best Practices for Developing with Artifactory on GCP
Hosting infrastructure on cloud-based services is becoming a standard in the tech industry. This comes as no surprise as multifaceted solutions for efficiency are the driving advantages of moving to the cloud. More specifically, some of the reasons that leave cloud solutions at an advantage include flexibility, cost and easier maintenance, allowing the team to allocate more time to application development.
JFrog Artifactory can be set up on all major cloud providers including Google Cloud Platform (GCP). This blog post outlines some best practices in setting up JFrog Artifactory, standalone or in a High Availability (HA) configuration, for development on GCP. Stay tuned for a future post where I’ll go through modifications that are needed to work with Artifactory on GCP to add layers of security and robustness for production systems.
Architecture
Artifactory architecture on GCP is comprised of three main components: networking, application, and storage.
Networking
The recommended setup includes four parts::
- A VPC (Virtual Private Cloud)
- Firewall Rules
- VMs (Virtual Machines)
- A Route
VPC
The VPC is the core container for the instance, and should be created in one region. The group of subnets and VPCs in the region will differ depending on whether you are running Artifactory as a standalone installation or as a high-availability, multi-node cluster.
| Setup | Recommendation |
| Standalone | A standalone installation requires a subnet for the Artifactory instance. If the number of artifacts your standalone instance hosts is more than 500,000, we also strongly recommend using an external database with no external IP addresses, and in this case, you will need a second subnet to ensure that only the application can access the database. |
| HA | An HA installation requires three or more subnets. One for the database, which should not have any external IP addresses. The second subnet should contain the primary node, and any additional subnets will host the secondary nodes. |
Firewall Rules
Firewall rules are created and applied at the network level to regulate traffic to and from your virtual machine. We recommend setting up firewall rules in the following use cases:
| Setup | Recommendation |
| External Database | If you are using an external database inside a private subnet, there should be a firewall rule allowing SSH access into the subnet. |
| External IP/hostname | Another firewall rule is required If you prefer to access your instance through an external IP/hostname instead of using “localhost”. |
You can learn how to create firewall rules in the GCP documentation.
VMs
The virtual machine(s) will work as a VPN gateway. The type and number of virtual machines will also be dependent on your Artifactory setup.
| Setup | Recommendation |
| Standalone with no external DB | One VM is required for a standalone Artifactory instance. |
| Standalone with an external DB | One VM is required for a standalone Artifactory instance and it may also include the NAT gateway. The NAT gateway may also be on a separate node which would then require another VM. In either case, the gateway must have an external IP. |
| HA | An HA installation requires a separate VM for each node. A VM for the primary node, and supplementary VMs for each additional subnet created for the secondary nodes. In addition, since HA requires an external database, putting the NAT gateway on a separate node would require an additional VM. |
Network Route(s)
A network route directs traffic through the two subnets for the Artifactory instances and databases to communicate with each other.
Application
The application is made up of three parts:
- The Artifactory instance(s)
- Reverse proxy
- Google Cloud load balancer
Artifactory Instance(s)
There are a variety of options for installing Artifactory on GCP according to the platform you are running, both for a standalone installation and an HA cluster. For a standalone installation, please refer to Installing Artifactory and for an HA cluster, please refer to HA Installation and Setup in the JFrog Artifactory User Guide. If you want to take advantage of features that container registry platforms can provide like auto-restart and auto-scaling, you can check out our Docker installation or our Helm Chart installation for Kubernetes. For details on requirements such as CPU, memory requirements and disk space usage, please refer to System Requirements in the JFrog Artifactory User Guide.
Reverse Proxy
There are different reasons you may choose to use a reverse proxy. You should also note that a reverse proxy is mandatory if you are using Artifactory as a Docker Registry.
Google Cloud Load Balancer
The load balancer efficiently distributes all requests coming in to the Artifactory instances. The Google Cloud Load Balancer is recommended as the most compatible load balancer for instances inside of GCP. This is the component through which your end users will engage with to access your Artifactory instance.
Storage
The storage component of Artifactory’s architecture on GCP includes:
- Cloud Storage
- External Database
Storage is comprised of data (binaries) and metadata. The binaries are stored in cloud storage while the metadata is managed in the database.
| Storage Manager | Recommendation |
| Cloud Storage | Obviously, if you’re on GCP, we recommend using Google Cloud Storage (GCS) to host your binaries. To configure Artifactory to use GCS, please refer to Google Cloud Storage in the JFrog Artifactory User Guide |
| Database | Artifactory comes with a built-in, embedded Derby database, however you may change this default to a number of other popular databases (this is required for an HA installation). For guidelines on how to select the database and details on how to configure Artifactory to use each supported database, please refer to Configuring the Database in the JFrog Artifactory User Guide |
Final Checklist
| Instance Type | Standalone without an external DB | Standalone with an external DB | HA |
|
Networking |
|||
| VPC | 1 | 1 | 1 |
| Subnets | 1 | 2 | 3+ |
| Firewall Rule | 1
* If you want an External IP/hostname |
1+
*one for the external DB, External IP/hostname (optional) |
1+ *one for the external DB, External IP/hostname (optional) |
| VM | 1 | 2+ | 3+ |
| Route | – | 1 | 1 |
|
Application |
|||
| Artifactory Instance | 1 | 1 | 2+ |
| Google Cloud Load Balancer | – | – | 1 |
|
Storage |
|||
| Cloud Storage | 1 | 1 | 1 |
| Database | – | 1 | 1 |
Don’t want all the bother?
If you don’t want to worry about all this configuration, JFrog Artifactory is available as a cloud-native, hosted service on GCP (and other major cloud providers). There are options for a subscription on a multi-tenanted configuration or a fully dedicated server. You can find the details on our website, and can even get your feet wet with a free trial.
