feature-image

Introduction

In large projects it is common to share libraries across applications. Typically, libraries are hosted either via public cloud repository like Maven Central or hosted in private repositories, and they are pulled when required.

Solution

Things to consider

  • Security - Internal libraries of an organization cannot be hosted in public repositories, and thus the need for a private repository arises.
  • Cost - Set up cost and Maintenance of the repository.

Hitherto de facto

Typical solution for the artifact management is to go with artifact repositories such as JFrog, Nexus, etc. Either install and manage them or use a managed service.

Of course both are secured. The former is costly in terms of effort required and the latter is costly in terms of the pricing of managed services.

Cloud options

When there is little efficiency often we ask this question “Is there a better way to solve this and add value to the delivery cycle?” and the answer is of course “Yes”.

Similar to other services offered, major public cloud vendors have solutions out of the box SaaS offerings for hosting artifact repository, and they also have managed services for hosting artifact needs.

Advantages of a native cloud solution

Cloud native solutions are cost-effective, easy set up, easy to use, availability and secure. With near zero management and maintenance requirements ease DevOps work load.

Why choose (GCP)Artifact Registry

GCP’s Artifactory Registry was an effective choice for our use case (as our application was relying GCP for build and hosting requirements) where we quickly need to have a maven repository with security and cost. The set-up & maintenance cost is almost zero, the operating costs to store the artifacts is free up to 0.5 GB and for every additional GB the cost is $0.10 and the network egress cost max $0.15 per GB.

Artifact Registry is a fully managed artifact repository service - you can use it to store container images, NPM packages, and Java artifacts, without having to setup any infrastructure and worry about availability or disk space.

As such it provides you total control your artifacts:

  • granular access control at project/repository level
  • maintain regional repositories
  • multiple repositories per project

Thus, Artifact Registry helps your organization deliver software at scale, reduce operational overhead, and thus free developers to focus on building your core application.

Installation

Let us setup a maven repository on GCP’s Artifact Registry and setup our project to push and pull our private artifacts to/from it.

Prerequisites

  1. GCP service account
  2. Have access permission for artifact registry.

Create a Maven Repository

1
2
3
gcloud artifacts repositories create REPOSITORY \
 -  -repository-format=maven  \
    [--location=LOCATION] 

Generate the pom configuration to add to your project:

1
2
3
4
gcloud artifacts print-settings mvn \
    --project=<PROJECT>         \
    --repository=<REPOSITORY>   \ 
    --location=<REGION>

Your project specific snippet is then generated. Make sure to insert this into your project’s pom.xml.

Sample snippet:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<project>
  <distributionManagement>
    <snapshotRepository>
      <id>artifact-registry</id>
      <url>artifactregistry://<!--your-private-repository-url--></url>
    </snapshotRepository>
  </distributionManagement>

  <repositories>
    <repository>
      <id>artifact-registry</id>
      <url>artifactregistry://<!--your-private-repository-url--></url>
      <releases>
        <enabled>false</enabled>
      </releases>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </repository>
  </repositories>

  <build>
    <extensions>
      <extension>
        <groupId>com.google.cloud.artifactregistry</groupId>
        <artifactId>artifactregistry-maven-wagon</artifactId>
        <version>2.1.0</version>
      </extension>
    </extensions>
  </build>
</project>

Configuration

First begin by generating the credentials file for your service account.

1
2
gcloud iam service-accounts keys create <KEY_FILE_PATH> \
    --iam-account=<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com

Now download this keyfile .json file to your local machine.

You need to add this file’s path to an environment variable named GOOGLE_APPLICATION_CREDENTIALS.

Follow your OS specific steps on setting a system environment variable.

Deploy an artifact

You can now successfully deploy your libraries to the repository through maven’s build lifecycle.

1
mvn clean package deploy

Or you can also manually add package to repo that were packaged outside of maven.

1
2
3
4
mvn deploy:deploy-file        \
    -Durl=artifactregistry://<your-private-repository-url>  \
    -DpomFile=example/pom.xml     \
    -Dfile=example/external.jar

Verify that your artifact is published

To verify that your artifact has been deployed to your private repository:

1
2
3
4
5
gcloud artifacts versions list 
    --package=PACKAGE           \
    --project=<PROJECT>         \
    [--repository=REPOSITORY]   \ 
    [--location=LOCATION]

Resolve maven project dependencies

You can now setup your applications to pull from your private repository.

To ensure that your application can resolve the private libraries, you may need to add repository & Google’s Artifact Registry Wagon to the project’s pom.xml so that you can to access your artifacts from the repository.

To include in all of your projects’ pom.xml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<project>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.google.cloud</groupId>
            <artifactId>spring-cloud-gcp-dependencies</artifactId>
            <version>3.2.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<repositories>
    <repository>
      <id>artifact-registry</id>
      <url>artifactregistry://<!--your-private-repository-url--></url>
    </repository>
</repositories>

<build>
    <extensions>
        <extension>
            <groupId>com.google.cloud.artifactregistry</groupId>
            <artifactId>artifactregistry-maven-wagon</artifactId>
            <version>2.1.4</version>
        </extension>
    </extensions>
</build>

That is it. Now your projects can pull any private artifact hosted on your GCP Artifact Registy during the maven build lifecycles.

1
mvn verify

Conclusion

Making use of shared libraries across common projects helps ease development workflows for large scale applications.

You can now have a managed cloud solution like Artifact Registry to help build and deploy your own libraries to a private Maven repository without having to work about maintaining or securing custom solutions.