Running Artifactory as a container is simple and straightforward, and involves the following basic steps:
Since the Artifactory instance running in a Docker container is mutable, all data and configuration files will be lost once the container is removed. If you want your data to persist (for example when upgrading to a new version), you should also follow the next step.
The Artifactory Docker image may be pulled from Bintray by executing the corresponding Docker command below depending on whether you are pulling Artifactory OSS or Artifactory Pro:
docker pull docker.bintray.io/jfrog/artifactory-pro:latest
docker pull docker.bintray.io/jfrog/artifactory-oss:latest
docker pull docker.bintray.io/jfrog/artifactory-cpp-ce
You can list the Docker images you have downloaded using the docker images command, which should display something like the following output:
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.bintray.io/jfrog/artifactory-pro latest da70b82904e7 2 days ago 861.5 MB ...
To start an Artifactory container, use the corresponding command below according to whether you are running Artifactory Pro or Artifactory OSS:
$ docker run --name artifactory -d -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest
$ docker run --name artifactory -d -p 8081:8081 docker.bintray.io/jfrog/artifactory-oss:latest
When running an Artifactory Docker container, you can pass in Java arguments using the
$ docker run --name artifactory -d -p 8081:8081 -e EXTRA_JAVA_OPTIONS=-Xmx8g docker.bintray.io/jfrog/artifactory-pro:latest
The entrypoint script of the Artifactory Pro Docker image accepts various environment variables. These are documented in the table below, and can be used to manipulate various HA-specific settings. Setting the following variables is particularly useful when using an orchestration tool such as Kubernetes or Docker Compose to spin up new Artifactory nodes. For more details on configuring the
|Determines whether the node is set as a Primary node or as a Member node in the cluster.||-|
|The value of the 'node.id' parameter in the ha-node.properties file.||node-$(hostname)|
|The IP of the container. This variable is used to compose a full context.url, only when the $HA_CONTEXT_URL variable is not set. Determined by running 'hostname -i'.||$(hostname -i)|
|The value of the 'context.url' parameter in the generated ha-node.properties file. This is the node URL exposed to cluster members. If not set, the $HA_HOST_IP variable will be used to derive the full context.url.||http://$HA_HOST_IP:8081/artifactory|
|The Hazelcast membership port of the node.||10002|
|Set this on a member node only if the nodes are not going to be a part of the same docker network, so that they're not reachable to each other by the container name, or if you the name of the primary node container is not "artifactory-node1". The entrypoint script would send an HTTP request to the primary node using this URL to wait for the Primary node to start up.|
|The value for the 'artifactory.ha.data.dir' parameter in the ha-node.properties file.||/var/opt/jfrog/artifactory/data|
|The value for the 'artifactory.ha.backup.dir' parameter in the ha-node.properties file.||/var/opt/jfrog/artifactory/backup|
For your data and configuration to remain once the Artifactory Docker container is removed, you need to store them on an external volume mounted to the Docker container. There are two ways to do this:
The external volume is a directory in your host's file system (such as /var/opt/jfrog/artifactory). When you pass this to the
docker run command, the Artifactory process will use it to read configuration and store its data.
To mount the above example, you would use the following command:
$ docker run --name artifactory-pro -d -v /var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest
This mounts the /var/opt/jfrog/artifactory directory on your host machine to the container's /var/opt/jfrog/artifactory and will then be used by Artifactory for configuration and data.
In this case, you create a docker named volume and pass it to the container. By default, the named volume is a local directory under
/var/lib/docker/volumes/<name>, but can be set to work with other locations. For more details, please refer to the Docker documentation for .
The example below creates a Docker named volume called artifactory_data and mounts it to the Artifactory container under /var/opt/jfrog/artifactory:
$ docker volume create --name artifactory5_data $ docker run --name artifactory-pro -d -v artifactory5_data:/var/opt/jfrog/artifactory -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest
In this case, even if the container is stopped and removed, the volume persists and can be attached to a new running container using the above
docker run command.
You can mount extra configuration files, such as
db.properties, that are needed for your Artifactory installation.
To do this, you need to mount the file or directory on the host into the Artifactory Docker container's
/artifactory_extra_conf folder. When the Artifactory Docker container starts, it will copy the files from
The files mounted into
$ docker run --name artifactory-pro -d -v /var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -v /conf/db.properties:/artifactory_extra_conf/db.properties -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest
Example 2: Passing in a custom binarystore.xml
$ docker run --name artifactory-pro -d -v /var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -v /conf/binarystore.xml:/artifactory_extra_conf/binarystore.xml -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest
By default, Artifactory runs with an embedded Derby Database that comes built-in, however, Artifactory supports additional databases. To switch to one of the other supported databases, please refer to Changing the Database.
The Artifactory OSS Docker image sources are available for download allowing you to build the image yourself. For details, please refer to Building Artifactory OSS.
Once the Artifactory container is up and running, you access Artifactory in the usual way by browsing to:
For example, if you are testing on your local machine you would use: http://localhost:8081/artifactory
This section describes different ways you can troubleshoot a running or stopped Docker container that is not functioning as expected.
docker ps command lists containers in your system.
$ docker ps # Lists running containers $ docker ps -a # Lists all containers
Artifactory logs are stored in the Artifactory container under
If you ran the container with a mounted volume for Artifactory data (
/var/opt/jfrog/artifactory/), you can also access the logs locally on your host.
An easy way to see the logged output of a running container is through the
docker logs command
$ docker logs <container name>
This will output all of the container's STDOUT and STDERR to the screen both for running and stopped containers.
You can connect to a running container's file system and open an interactive command prompt in the container with the
docker exec command
$ docker exec -it <container name> /bin/bash
This will open a command prompt in the running Artifactory container, logging you in as root and placing you in the / directory.
There are cases where you want to run the container, but not start up Artifactory. To do this, you need to override the configured entrypoint script using
docker run --entrypoint=bash
$ docker run -it --entrypoint=/bin/bash -v /var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -p 8081:8018 docker.bintray.io/jfrog/artifactory-pro:latest
This will run the container, presenting you with a prompt in the container, but without executing the
You can then make changes to the container configuration execute
/entrypoint-artifactory.sh to start up Artifactory in your container.
<iframe width="560" height="315" src="https://www.youtube.com/embed/SG9rtyXsEXU" frameborder="0" allowfullscreen></iframe>