The [Artifactory replicator](https://www.jfrog.com/confluence/display/RTF/Replicator) is used with an [Enterprise Plus](https://www.jfrog.com/confluence/display/EP/Welcome+to+JFrog+Enterprise+Plus) license.
```bash
## Artifactory replicator is disabled by default. When the replicator is enabled, the replicator.publicUrl parameter is required. To enable it use the following:
### Deploying Artifactory for small/medium/large instllations
In the chart directory, we have added three values files, one for each installation type - small/medium/large. These values files are recommendations for setting resources requests and limits for your installation. The values are derived from the following [documentation](https://www.jfrog.com/confluence/display/EP/Installing+on+Kubernetes#InstallingonKubernetes-Systemrequirements). You can find them in the corresponding chart directory - values-small.yaml, values-medium.yaml and values-large.yaml
### Accessing Artifactory
**NOTE:** It might take a few minutes for Artifactory's public IP to become available, and the nodes to complete initial setup.
Follow the instructions outputted by the install command to get the Artifactory IP and URL to access it.
### Updating Artifactory
Once you have a new chart version, you can update your deployment with
```bash
helm upgrade artifactory-ha jfrog/artifactory-ha
```
If artifactory was installed without providing a value to postgresql.postgresqlPassword (a password was autogenerated), follow these instructions:
1. Get the current password by running:
```bash
POSTGRES_PASSWORD=$(kubectl get secret -n <namespace> <myrelease>-postgresql -ojsonpath="{.data.postgresql-password}" | base64--decode)
```
2. Upgrade the release by passing the previously auto-generated secret:
This will apply any configuration changes on your existing deployment.
### Artifactory memory and CPU resources
The Artifactory HA Helm chart comes with support for configured resource requests and limits to all pods. By default, these settings are commented out.
It is **highly** recommended to set these so you have full control of the allocated resources and limits.
See more information on [setting resources for your Artifactory based on planned usage](https://www.jfrog.com/confluence/display/RTF/System+Requirements#SystemRequirements-RecommendedHardware).
```bash
# Example of setting resource requests and limits to all pods (including passing java memory settings to Artifactory)
> Artifactory java memory parameters can (and should) also be set to match the allocated resources with `artifactory.[primary|node].javaOpts.xms` and `artifactory.[primary|node].javaOpts.xmx`.
Get more details on configuring Artifactory in the [official documentation](https://www.jfrog.com/confluence/).
### Artifactory storage
Artifactory HA support a wide range of storage back ends. You can see more details on [Artifactory HA storage options](https://www.jfrog.com/confluence/display/RTF/HA+Installation+and+Setup#HAInstallationandSetup-SettingUpYourStorageConfiguration)
In this chart, you set the type of storage you want with `artifactory.persistence.type` and pass the required configuration settings.
The default storage in this chart is the `file-system` replication, where the data is replicated to all nodes.
> **IMPORTANT:** All storage configurations (except NFS) come with a default `artifactory.persistence.redundancy` parameter.
This is used to set how many replicas of a binary should be stored in the cluster's nodes.
Once this value is set on initial deployment, you can not update it using helm.
It is recommended to set this to a number greater than half of your cluster's size, and never scale your cluster down to a size smaller than this number.
#### Existing volume claim
###### Primary node
In order to use an existing volume claim for the Artifactory primary storage, you need to:
- Create a persistent volume claim by the name `volume-<release-name>-artifactory-ha-primary-0` e.g `volume-myrelease-artifactory-ha-primary-0`
- Pass a parameter to `helm install` and `helm upgrade`
In order to use an existing volume claim for the Artifactory member nodes storage, you need to:
- Create persistent volume claims according to the number of replicas defined at `artifactory.node.replicaCount` by the names `volume-<release-name>-artifactory-ha-member-<ordinal-number>`, e.g `volume-myrelease-artifactory-ha-member-0` and `volume-myrelease-artifactory-ha-primary-1`.
- Pass a parameter to `helm install` and `helm upgrade`
An example that shows 2 existing claims to be used:
```
myexample-data-pvc-0
myexample-data-pvc-1
myexample-backup-pvc
```
- Set the artifactory.persistence.fileSystem.existingSharedClaim.enabled in values.yaml to true:
```
-- set artifactory.persistence.fileSystem.existingSharedClaim.enabled=true
-- set artifactory.persistence.fileSystem.existingSharedClaim.numberOfExistingClaims=2
```
#### NFS
To use an NFS server as your cluster's storage, you need to
- Setup an NFS server. Get its IP as `NFS_IP`
- Create a `data` and `backup` directories on the NFS exported directory with write permissions to all
- Pass NFS parameters to `helm install` and `helm upgrade`
```bash
...
--set artifactory.persistence.type=nfs \
--set artifactory.persistence.nfs.ip=${NFS_IP}\
...
```
#### Google Storage
To use a Google Storage bucket as the cluster's filestore. See [Google Storage Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-GoogleStorageBinaryProvider)
- Pass Google Storage parameters to `helm install` and `helm upgrade`
To use an AWS S3 bucket as the cluster's filestore. See [S3 Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-S3BinaryProvider)
- Pass AWS S3 parameters to `helm install` and `helm upgrade`
**NOTE:** Make sure S3 `endpoint` and `region` match. See [AWS documentation on endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html)
#### Microsoft Azure Blob Storage
To use Azure Blob Storage as the cluster's filestore. See [Azure Blob Storage Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-AzureBlobStorageClusterBinaryProvider)
- Pass Azure Blob Storage parameters to `helm install` and `helm upgrade`
**NOTE:** In either case, make sure to pass the same master key on all future calls to `helm install` and `helm upgrade`! In the first case, this means always passing `--set artifactory.masterKey=${MASTER_KEY}`. In the second, this means always passing `--set artifactory.masterKeySecretName=my-secret` and ensuring the contents of the secret remain unchanged.
### Install Artifactory HA license
For activating Artifactory HA, you must install an appropriate license. There are three ways to manage the license. **Artifactory UI**, **REST API**, or a **Kubernetes Secret**.
The easier and recommended way is the **Artifactory UI**. Using the **Kubernetes Secret** or **REST API** is for advanced users and is better suited for automation.
**IMPORTANT:** You should use only one of the following methods. Switching between them while a cluster is running might disable your Artifactory HA cluster!
##### Artifactory UI
Once primary cluster is running, open Artifactory UI and insert the license(s) in the UI. See [HA installation and setup](https://www.jfrog.com/confluence/display/RTF/HA+Installation+and+Setup) for more details. **Note that you should enter all licenses at once, with each license is separated by a newline.** If you add the licenses one at a time, you may get redirected to a node without a license and the UI won't load for that node.
##### REST API
You can add licenses via REST API (https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-InstallHAClusterLicenses). Note that the REST API expects "\n" for the newlines in the licenses.
##### Kubernetes Secret
You can deploy the Artifactory license(s) as a [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/).
Prepare a text file with the license(s) written in it. If writing multiple licenses (must be in the same file), it's important to put **two new lines between each license block**!
```bash
# Create the Kubernetes secret (assuming the local license file is 'art.lic')
**NOTE:** This method is relevant for initial deployment only! Once Artifactory is deployed, you should not keep passing these parameters as the license is already persisted into Artifactory's storage (they will be ignored).
Updating the license should be done via Artifactory UI or REST API.
##### Create the secret as part of the helm release
**NOTE:** This method is relevant for initial deployment only! Once Artifactory is deployed, you should not keep passing these parameters as the license is already persisted into Artifactory's storage (they will be ignored).
Updating the license should be done via Artifactory UI or REST API.
If you want to keep managing the artifactory license using the same method, you can use the copyOnEveryStartup example shown in the values.yaml file
### Configure NetworkPolicy
NetworkPolicy specifies what ingress and egress is allowed in this namespace. It is encouraged to be more specific whenever possible to increase security of the system.
In the `networkpolicy` section of values.yaml you can specify a list of NetworkPolicy objects.
For podSelector, ingress and egress, if nothing is provided then a default `- {}` is applied which is to allow everything.
A full (but very wide open) example that results in 2 NetworkPolicy objects being created:
```yaml
networkpolicy:
# Allows all ingress and egress to/from artifactory primary and member pods.
-name:artifactory
podSelector:
matchLabels:
app:artifactory-ha
egress:
-{}
ingress:
-{}
# Allows connectivity from artifactory-ha pods to postgresql pods, but no traffic leaving postgresql pod.
-name:postgresql
podSelector:
matchLabels:
app:postgresql
ingress:
-from:
-podSelector:
matchLabels:
app:artifactory-ha
```
### Artifactory JMX Configuration
** You can see some information about the exposed MBeans here - https://www.jfrog.com/confluence/display/RTF/Artifactory+JMX+MBeans
**IMPORTANT:** Bootstrapping Artifactory needs license. Pass license as shown in above section.
* User guide to [bootstrap Artifactory Global Configuration](https://www.jfrog.com/confluence/display/RTF/Configuration+Files#ConfigurationFiles-BootstrappingtheGlobalConfiguration)
* User guide to [bootstrap Artifactory Security Configuration](https://www.jfrog.com/confluence/display/RTF/Configuration+Files#ConfigurationFiles-BootstrappingtheSecurityConfiguration)
Create `bootstrap-config.yaml` with artifactory.config.import.xml and security.import.xml as shown below:
A key feature in Artifactory HA is the ability to set an initial cluster size with `--set artifactory.node.replicaCount=${CLUSTER_SIZE}` and if needed, resize it.
##### Before scaling
**IMPORTANT:** When scaling, you need to explicitly pass the database password if it's an auto generated one (this is the default with the enclosed PostgreSQL helm chart).
Get the current database password
```bash
export DB_PASSWORD=$(kubectl get $(kubectl get secret -o name | grep postgresql) -o jsonpath="{.data.postgresql-password}" | base64 --decode)
```
Use `--set postgresql.postgresqlPassword=${DB_PASSWORD}` with every scale action to prevent a miss configured cluster!
##### Scale up
Let's assume you have a cluster with **2** member nodes, and you want to scale up to **3** member nodes (a total of 4 nodes).
- **NOTE:** Since Artifactory is running as a Kubernetes Stateful Set, the removal of the node will **not** remove the persistent volume. You need to explicitly remove it
```bash
# List PVCs
kubectl get pvc
# Remove the PVC with highest ordinal!
# In this example, the highest node ordinal was 2, so need to remove its storage.
kubectl delete pvc volume-artifactory-node-2
```
### Use an external Database
#### PostgreSQL
There are cases where you will want to use external PostgreSQL with a different database name e.g. `my-artifactory-db`, then you need set a custom PostgreSQL connection URL, where `my-artifactory-db` is the database name.
**NOTE:** You must set `postgresql.enabled=false` in order for the chart to use the `database.*` parameters. Without it, they will be ignored!
#### Using pre-existing Kubernetes Secret
If you store your database credentials in a pre-existing Kubernetes `Secret`, you can specify them via `database.secrets` instead of `database.user` and `database.password`:
```bash
# Create a secret containing the database credentials
This will completely delete your Artifactory HA cluster.
**NOTE:** Since Artifactory is running as Kubernetes Stateful Sets, the removal of the helm release will **not** remove the persistent volumes. You need to explicitly remove them
```bash
kubectl delete pvc -l release=artifactory-ha
```
See more details in the official [Kubernetes Stateful Set removal page](https://kubernetes.io/docs/tasks/run-application/delete-stateful-set/)
### Custom Docker registry for your images
If you need to pull your Docker images from a private registry (for example, when you have a custom image with a MySQL database driver), you need to create a
[Kubernetes Docker registry secret](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) and pass it to helm
```bash
# Create a Docker registry secret called 'regsecret'
There are cases where a special, unsupported init processes is needed like checking something on the file system or testing something before spinning up the main container.
For this, there is a section for writing custom init containers before and after the predefined init containers in the [values.yaml](values.yaml) . By default it's commented out
```yaml
artifactory:
## Add custom init containers executed before predefined init containers
customInitContainersBegin: |
## Init containers template goes here ##
## Add custom init containers executed after predefined init containers
customInitContainers: |
## Init containers template goes here ##
```
### Custom sidecar containers
There are cases where an extra sidecar container is needed. For example monitoring agents or log collection.
For this, there is a section for writing a custom sidecar container in the [values.yaml](values.yaml). By default it's commented out
```yaml
artifactory:
## Add custom sidecar containers
customSidecarContainers: |
## Sidecar containers template goes here ##
```
You can configure the sidecar to run as a custom user if needed by setting the following in the container template
```yaml
# Example of running container as root (id 0)
securityContext:
runAsUser: 0
fsGroup: 0
```
### Custom volumes
If you need to use a custom volume in a custom init or sidecar container, you can use this option.
For this, there is a section for defining custom volumes in the [values.yaml](values.yaml). By default it's commented out
```yaml
artifactory:
## Add custom volumes
customVolumes: |
## Custom volume comes here ##
```
### Add Artifactory User Plugin during installation
If you need to add [Artifactory User Plugin](https://github.com/jfrog/artifactory-user-plugins), you can use this option.
Create a secret with [Artifactory User Plugin](https://github.com/jfrog/artifactory-user-plugins) by following command:
Alternatively, you may be in a situation in which you would like to create a secret in a Helm chart that depends on this chart. In this scenario, the name of the secret is likely dynamically generated via template functions, so passing a statically named secret isn't possible. In this case, the chart supports evaluating strings as templates via the [`tpl`](https://helm.sh/docs/charts_tips_and_tricks/#using-the-tpl-function) function - simply pass the raw string containing the templating language used to name your secret as a value instead by adding the following to your chart's `values.yaml` file:
```yaml
artifactory-ha: # Name of the artifactory-ha dependency
artifactory:
userPluginSecrets:
- '{{ template "my-chart.fullname" . }}'
```
NOTE: By defining userPluginSecrets, this overrides any pre-defined plugins from the container image that are stored in /tmp/plugins. At this time [artifactory-pro:6.9.0](https://bintray.com/jfrog/artifactory-pro) is distributed with `internalUser.groovy` plugin. If you need this plugin in addition to your user plugins, you should include these additional plugins as part of your userPluginSecrets.
## Configuration
The following table lists the configurable parameters of the artifactory chart and their default values.
| `artifactory.userPluginSecrets` | Array of secret names for Artifactory user plugins | |
| `artifactory.masterKey` | Artifactory Master Key. Can be generated with `openssl rand -hex 32` |`FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF`|
| `artifactory.masterKeySecretName` | Artifactory Master Key secret name | |
| `artifactory.accessAdmin.ip` | Artifactory access-admin ip to be set upon startup, can use (*) for 0.0.0.0| 127.0.0.1 |
| `artifactory.accessAdmin.password` | Artifactory access-admin password to be set upon startup| |
| `artifactory.accessAdmin.secret` | Artifactory access-admin secret name | |
| `artifactory.accessAdmin.dataKey` | Artifactory access-admin secret data key | |
| `artifactory.preStartCommand` | Command to run before entrypoint starts | |
| `artifactory.postStartCommand` | Command to run after container starts | |
| `artifactory.license.licenseKey` | Artifactory license key. Providing the license key as a parameter will cause a secret containing the license key to be created as part of the release. Use either this setting or the license.secret and license.dataKey. If you use both, the latter will be used. | |
| `artifactory.license.secret` | Artifactory license secret name | |
| `artifactory.license.dataKey`| Artifactory license secret data key | |
| `artifactory.service.name` | Artifactory service name to be set in Nginx configuration | `artifactory` |
| `artifactory.service.type` | Artifactory service type | `ClusterIP` |
| `artifactory.service.clusterIP`| Specific cluster IP or `None` for headless services | `nil` |
| `artifactory.service.pool` | Artifactory instances to be in the load balancing pool. `members` or `all` | `members` |
| `artifactory.externalPort` | Artifactory service external port | `8081` |
| `artifactory.internalPort` | Artifactory service internal port | `8081` |
| `artifactory.internalPortReplicator` | Replicator service internal port | `6061` |
| `artifactory.externalPortReplicator` | Replicator service external port | `6061` |
| `artifactory.extraEnvironmentVariables` | Extra environment variables to pass to Artifactory. Supports evaluating strings as templates via the [`tpl`](https://helm.sh/docs/charts_tips_and_tricks/#using-the-tpl-function) function. See [documentation](https://www.jfrog.com/confluence/display/RTF/Installing+with+Docker#InstallingwithDocker-SupportedEnvironmentVariables) | |
| `artifactory.readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | 60 |
| `artifactory.readinessProbe.periodSeconds` | How often to perform the probe | 10 |
| `artifactory.readinessProbe.timeoutSeconds` | When the probe times out | 10 |
| `artifactory.readinessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed. | 1 |
| `artifactory.readinessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | 10 |
| `artifactory.copyOnEveryStartup` | List of files to copy on startup from source (which is absolute) to target (which is relative to ARTIFACTORY_HOME | |
| `artifactory.deleteDBPropertiesOnStartup` | Whether to delete the ARTIFACTORY_HOME/etc/db.properties file on startup. Disabling this will remove the ability for the db.properties to be updated with any DB-related environment variables change (e.g. DB_HOST, DB_URL) | `true` |
| `artifactory.persistence.cacheProviderDir` | the root folder of binaries for the filestore cache. If the value specified starts with a forward slash ("/") it is considered the fully qualified path to the filestore folder. Otherwise, it is considered relative to the *baseDataDir*. | `cache` |
| `artifactory.persistence.type` | Artifactory HA storage type | `file-system` |
| `artifactory.persistence.redundancy` | Artifactory HA storage redundancy | `3` |
| `artifactory.persistence.nfs.ip` | NFS server IP | |
| `artifactory.persistence.nfs.haDataMount` | NFS data directory | `/data` |
| `artifactory.persistence.awsS3.refreshCredentials` | AWS S3 renew credentials on expiration | `true` (When roleName is used, this parameter will be set to true) |
| `artifactory.persistence.awsS3.testConnection` | AWS S3 test connection on start up | `false` |
| `artifactory.persistence.awsS3.s3AwsVersion` | AWS S3 signature version | `AWS4-HMAC-SHA256` |
| `artifactory.primary.javaOpts.corePoolSize` | The number of async processes that can run in parallel in the primary node - https://jfrog.com/knowledge-base/how-do-i-tune-artifactory-for-heavy-loads/ | `16` |
| `artifactory.node.javaOpts.corePoolSize` | The number of async processes that can run in parallel in the member nodes - https://jfrog.com/knowledge-base/how-do-i-tune-artifactory-for-heavy-loads/ | `16` |
| `ingress.defaultBackend.enabled` | If true, the default `backend` will be added using serviceName and servicePort | `true` |
| `ingress.annotations` | Ingress annotations, which are written out if annotations section exists in values. Everything inside of the annotations section will appear verbatim inside the resulting manifest. See `Ingress annotations` section below for examples of how to leverage the annotations, specifically for how to enable docker authentication. | |
| `ingress.additionalRules` | Ingress additional rules to be added to the Artifactory ingress. | `[]` |
| `nginx.enabled` | Deploy nginx server | `true` |
If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [cert-manager](https://github.com/jetstack/cert-manager)), please refer to the documentation for that mechanism.
To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret in the namespace:
Include the secret's name, along with the desired hostnames, in the Artifactory Ingress TLS section of your custom `values.yaml` file:
```yaml
ingress:
## If true, Artifactory Ingress will be created
##
enabled: true
## Artifactory Ingress hostnames
## Must be provided if Ingress is enabled
##
hosts:
- artifactory.domain.com
annotations:
kubernetes.io/tls-acme: "true"
## Artifactory Ingress TLS configuration
## Secrets must be manually created in the namespace
##
tls:
- secretName: artifactory-tls
hosts:
- artifactory.domain.com
```
### Ingress annotations
This example specifically enables Artifactory to work as a Docker Registry using the Repository Path method. See [Artifactory as Docker Registry](https://www.jfrog.com/confluence/display/RTF/Getting+Started+with+Artifactory+as+a+Docker+Registry) documentation for more information about this setup.
# JFrog Artifactory Reverse Proxy Settings using Nginx
#### Reverse Proxy
* To use Artifactory as docker registry it's mandatory to use Reverse Proxy.
* Artifactory provides a Reverse Proxy Configuration Generator screen in which you can fill in a set of fields to generate
the required configuration snippet which you can then download and install directly in the corresponding directory of your reverse proxy server.
* To learn about configuring NGINX or Apache for reverse proxy refer to documentation provided on [JFrog wiki](https://www.jfrog.com/confluence/display/RTF/Configuring+a+Reverse+Proxy)
* By default Artifactory helm chart uses Nginx for reverse proxy and load balancing.
**Note**: Nginx image distributed with Artifactory helm chart is custom image managed and maintained by JFrog.
#### Features of Artifactory Nginx
* Provides default configuration with self signed SSL certificate generated on each helm install/upgrade.
* Persist configuration and SSL certificate in `/var/opt/jfrog/nginx` directory
#### Changing the default Artifactory nginx conf
Use a values.yaml file for changing the value of nginx.mainConf or nginx.artifactoryConf
These configuration will be mounted to the nginx container using a configmap.
For example:
1. Create a values file `nginx-values.yaml` with the following values:
This file describes special upgrade notes needed at specific versions
## Upgrade from 0.X to 1.X
**DOWNTIME IS REQUIRED FOR AN UPGRADE!**
* If this is a new deployment or you already use an external database (`postgresql.enabled=false`), these changes **do not affect you!**
* PostgreSQL sub chart was upgraded to version `6.5.x`. This version is not backward compatible with the old version (`0.9.5`)!
* Note the following **PostgreSQL** Helm chart changes
* The chart configuration has changed! See [values.yaml](values.yaml) for the new keys used
***PostgreSQL** is deployed as a StatefulSet
* See [PostgreSQL helm chart](https://hub.helm.sh/charts/stable/postgresql) for all available configurations
* Upgrade
* Due to breaking changes in the **PostgreSQL** Helm chart, a migration of the database is needed from the old to the new database
* The recommended migration process is the [full system export and import](https://www.jfrog.com/confluence/display/RTF/Importing+and+Exporting)
***NOTE:** To save time, export only metadata and configuration (check `Exclude Content` in the `System Import & Export`) since the Artifactory filestore is persisted
* Upgrade steps:
1. Block user access to Artifactory (do not shutdown)
a. Scale down the cluster to primary node only (`node.replicaCount=0`) so the exported db and configuration will be kept on one known node (the primary)
b. If your Artifactory HA K8s service is set to member nodes only (`service.pool=members`) you will need to access the primary node directly (use `kubectl port-forward`)
2. Perform `Export System` from the `Admin` -> `Import & Export` -> `System` -> `Export System`
a. Check `Exclude Content` to save export size (as Artifactory filestore will persist across upgrade)
b. Choose to save the export on the persisted Artifactory volume (`/var/opt/jfrog/artifactory/`)
c. Click `Export` (this can take some time)
3. Run the `helm upgrade` with the new version. Old PostgreSQL will be removed and new one deployed
a. You must pass explicit "ready for upgrade flag" with `--set databaseUpgradeReady=yes`. Failing to provide this will block the upgrade!
4. Once ready, open Artifactory UI (you might need to re-enter a valid license). Skip all onboarding wizard steps
a. **NOTE:** Don't worry you can't see the old config and files. It will all restore with the system import in the next step
5. Perform `Import System` from the `Admin` -> `Import & Export` -> `System` -> `Import System`
a. Browse to where the export was saved Artifactory volume (`/var/opt/jfrog/artifactory/<directory-you-set>`)
b. Click `Import` (this can take some time)
6. Restore access to Artifactory
a. Scale the cluster member nodes back to the original size
* Artifactory should now be ready to get back to normal operation
Universal Repository Manager supporting all major packaging formats, build tools and CI servers.
## Chart Details
This chart will do the following:
* Deploy Artifactory highly available cluster. 1 primary node and 2 member nodes.
* Deploy a PostgreSQL database
* Deploy an Nginx server(optional)
## Useful links
Blog: [Herd Trust Into Your Rancher Labs Multi-Cloud Strategy with Artifactory](https://jfrog.com/blog/herd-trust-into-your-rancher-labs-multi-cloud-strategy-with-artifactory/)
## Activate Your Artifactory Instance
Don't have a license? Please send an email to [rancher-jfrog-licenses@jfrog.com](mailto:rancher-jfrog-licenses@jfrog.com) to get it.
[PostgreSQL](https://www.postgresql.org/) is an object-relational database management system (ORDBMS) with an emphasis on extensibility and on standards-compliance.
## TL;DR;
```console
$helm install stable/postgresql
```
## Introduction
This chart bootstraps a [PostgreSQL](https://github.com/bitnami/bitnami-docker-postgresql) deployment on a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.
Bitnami charts can be used with [Kubeapps](https://kubeapps.com/) for deployment and management of Helm Charts in clusters. This chart has been tested to work with NGINX Ingress, cert-manager, fluentd and Prometheus on top of the [BKPR](https://kubeprod.io/).
## Prerequisites
- Kubernetes 1.12+
- Helm 2.11+ or Helm 3.0-beta3+
- PV provisioner support in the underlying infrastructure
## Installing the Chart
To install the chart with the release name `my-release`:
```console
$helm install--name my-release stable/postgresql
```
The command deploys PostgreSQL on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation.
> **Tip**: List all releases using `helm list`
## Uninstalling the Chart
To uninstall/delete the `my-release` deployment:
```console
$helm delete my-release
```
The command removes all the Kubernetes components associated with the chart and deletes the release.
## Parameters
The following tables lists the configurable parameters of the PostgreSQL chart and their default values.
| `replication.user` | Replication user | `repl_user` |
| `replication.password` | Replication user password | `repl_password` |
| `replication.slaveReplicas` | Number of slaves replicas | `1` |
| `replication.synchronousCommit` | Set synchronous commit mode. Allowed values: `on`, `remote_apply`, `remote_write`, `local` and `off` | `off` |
| `replication.numSynchronousReplicas` | Number of replicas that will have synchronous replication. Note: Cannot be greater than `replication.slaveReplicas`. | `0` |
| `postgresqlExtendedConf` | Extended Runtime Config Parameters (appended to main or default configuration) | `nil` |
| `pgHbaConfiguration` | Content of pg\_hba.conf | `nil (do not create pg_hba.conf)` |
| `configurationConfigMap` | ConfigMap with the PostgreSQL configuration files (Note: Overrides `postgresqlConfiguration` and `pgHbaConfiguration`). The value is evaluated as a template. | `nil` |
| `extendedConfConfigMap` | ConfigMap with the extended PostgreSQL configuration files. The value is evaluated as a template. | `nil` |
| `initdbScripts` | Dictionary of initdb scripts | `nil` |
| `initdbScriptsConfigMap` | ConfigMap with the initdb scripts (Note: Overrides `initdbScripts`). The value is evaluated as a template. | `nil` |
| `initdbScriptsSecret` | Secret with initdb scripts that contain sensitive information (Note: can be used with `initdbScriptsConfigMap` or `initdbScripts`). The value is evaluated as a template. | `nil` |
| `service.type` | Kubernetes Service type | `ClusterIP` |
| `service.port` | PostgreSQL port | `5432` |
| `service.nodePort` | Kubernetes Service nodePort | `nil` |
| `service.annotations` | Annotations for PostgreSQL service, the value is evaluated as a template. | {} |
| `service.loadBalancerIP` | loadBalancerIP if service type is `LoadBalancer` | `nil` |
| `service.loadBalancerSourceRanges` | Address that are allowed when svc is LoadBalancer | [] |
| `schedulerName` | Name of the k8s scheduler (other than default) | `nil` |
| `persistence.enabled` | Enable persistence using PVC | `true` |
| `persistence.existingClaim` | Provide an existing `PersistentVolumeClaim`, the value is evaluated as a template. | `nil` |
| `persistence.mountPath` | Path to mount the volume at | `/bitnami/postgresql` |
| `persistence.subPath` | Subdirectory of the volume to mount at | `""` |
| `persistence.storageClass` | PVC Storage Class for PostgreSQL volume | `nil` |
| `securityContext.fsGroup` | Group ID for the container | `1001` |
| `securityContext.runAsUser` | User ID for the container | `1001` |
| `serviceAccount.enabled` | Enable service account (Note: Service Account will only be automatically created if `serviceAccount.name` is not set) | `false` |
| `serviceAcccount.name` | Name of existing service account | `nil` |
| `livenessProbe.enabled` | Would you like a livenessProbe to be enabled | `true` |
> **Tip**: You can use the default [values.yaml](values.yaml)
## Configuration and installation details
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
### Production configuration and horizontal scaling
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
- Enable replication:
```diff
- replication.enabled: false
+ replication.enabled: true
```
- Number of slaves replicas:
```diff
- replication.slaveReplicas: 1
+ replication.slaveReplicas: 2
```
- Set synchronous commit mode:
```diff
- replication.synchronousCommit: "off"
+ replication.synchronousCommit: "on"
```
- Number of replicas that will have synchronous replication:
```diff
- replication.numSynchronousReplicas: 0
+ replication.numSynchronousReplicas: 1
```
- Start a prometheus exporter:
```diff
- metrics.enabled: false
+ metrics.enabled: true
```
To horizontally scale this chart, you can use the `--replicas` flag to modify the number of nodes in your PostgreSQL deployment. Also you can use the `values-production.yaml` file or modify the parameters shown above.
### Change PostgreSQL version
To modify the PostgreSQL version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/postgresql/tags/) using the `image.tag` parameter. For example, `image.tag=12.0.0-debian-9-r0`
### postgresql.conf / pg_hba.conf files as configMap
This helm chart also supports to customize the whole configuration file.
Add your custom file to "files/postgresql.conf" in your working directory. This file will be mounted as configMap to the containers and it will be used for configuring the PostgreSQL server.
Alternatively, you can specify PostgreSQL configuration parameters using the `postgresqlConfiguration` parameter as a dict, using camelCase, e.g. {"sharedBuffers": "500MB"}.
In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the `configurationConfigMap` parameter. Note that this will override the two previous options.
### Allow settings to be loaded from files other than the default `postgresql.conf`
If you don't want to provide the whole PostgreSQL configuration file and only specify certain parameters, you can add your extended `.conf` files to "files/conf.d/" in your working directory.
Those files will be mounted as configMap to the containers adding/overwriting the default configuration using the `include_dir` directive that allows settings to be loaded from files other than the default `postgresql.conf`.
Alternatively, you can also set an external ConfigMap with all the extra configuration files. This is done by setting the `extendedConfConfigMap` parameter. Note that this will override the previous option.
### Initialize a fresh instance
The [Bitnami PostgreSQL](https://github.com/bitnami/bitnami-docker-postgresql) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, they must be located inside the chart folder `files/docker-entrypoint-initdb.d` so they can be consumed as a ConfigMap.
Alternatively, you can specify custom scripts using the `initdbScripts` parameter as dict.
In addition to these options, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `initdbScriptsConfigMap` parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the `initdbScriptsSecret` parameter.
The allowed extensions are `.sh`, `.sql` and `.sql.gz`.
### Metrics
The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9187) is not exposed and it is expected that the metrics are collected from inside the k8s cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml).
The exporter allows to create custom metrics from additional SQL queries. See the Chart's `values.yaml` for an example and consult the [exporters documentation](https://github.com/wrouesnel/postgres_exporter#adding-new-metrics-via-a-config-file) for more details.
### Use of global variables
In more complex scenarios, we may have the following tree of dependencies
The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL credentials, so one option for deploying could be deploy Chart 1 with the following parameters:
```
postgresql.postgresqlPassword=testtest
subchart1.postgresql.postgresqlPassword=testtest
subchart2.postgresql.postgresqlPassword=testtest
postgresql.postgresqlDatabase=db1
subchart1.postgresql.postgresqlDatabase=db1
subchart2.postgresql.postgresqlDatabase=db1
```
If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows:
```
global.postgresql.postgresqlPassword=testtest
global.postgresql.postgresqlDatabase=db1
```
This way, the credentials will be available in all of the subcharts.
## Persistence
The [Bitnami PostgreSQL](https://github.com/bitnami/bitnami-docker-postgresql) image stores the PostgreSQL data and configurations at the `/bitnami/postgresql` path of the container.
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
## NetworkPolicy
To enable network policy for PostgreSQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`.
For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for _all_ pods in the namespace:
With NetworkPolicy enabled, traffic will be limited to just port 5432.
For more precise policy, set `networkPolicy.allowExternal=false`. This will only allow pods with the generated client label to connect to PostgreSQL.
This label will be displayed in the output of a successful install.
## Differences between Bitnami PostgreSQL image and [Docker Official](https://hub.docker.com/_/postgres) image
- The Docker Official PostgreSQL image does not support replication. If you pass any replication environment variable, this would be ignored. The only environment variables supported by the Docker Official image are POSTGRES_USER, POSTGRES_DB, POSTGRES_PASSWORD, POSTGRES_INITDB_ARGS, POSTGRES_INITDB_WALDIR and PGDATA. All the remaining environment variables are specific to the Bitnami PostgreSQL image.
- The Bitnami PostgreSQL image is non-root by default. This requires that you run the pod with `securityContext` and updates the permissions of the volume with an `initContainer`. A key benefit of this configuration is that the pod follows security best practices and is prepared to run on Kubernetes distributions with hard security constraints like OpenShift.
### Deploy chart using Docker Official PostgreSQL Image
From chart version 4.0.0, it is possible to use this chart with the Docker Official PostgreSQL image.
Besides specifying the new Docker repository and tag, it is important to modify the PostgreSQL data directory and volume mount point. Basically, the PostgreSQL data dir cannot be the mount point directly, it has to be a subdirectory.
```
helm install --name postgres \
--set image.repository=postgres \
--set image.tag=10.6 \
--set postgresqlDataDir=/data/pgdata \
--set persistence.mountPath=/data/ \
stable/postgresql
```
## Upgrade
It's necessary to specify the existing passwords while performing an upgrade to ensure the secrets are not updated with invalid randomly generated passwords. Remember to specify the existing values of the `postgresqlPassword` and `replication.password` parameters when upgrading the chart:
```bash
$ helm upgrade my-release bitnami/influxdb \
--setpostgresqlPassword=[POSTGRESQL_PASSWORD] \
--set replication.password=[REPLICATION_PASSWORD]
```
> Note: you need to substitute the placeholders _[POSTGRESQL_PASSWORD]_, and _[REPLICATION_PASSWORD]_ with the values obtained from instructions in the installation notes.
## 5.0.0
In this version, the **chart is using PostgreSQL 11 instead of PostgreSQL 10**. You can find the main difference and notable changes in the following links: [https://www.postgresql.org/about/news/1894/](https://www.postgresql.org/about/news/1894/) and [https://www.postgresql.org/about/featurematrix/](https://www.postgresql.org/about/featurematrix/).
For major releases of PostgreSQL, the internal data storage format is subject to change, thus complicating upgrades, you can see some errors like the following one in the logs:
```bash
Welcome to the Bitnami postgresql container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues
Send us your feedback at containers@bitnami.com
INFO ==>** Starting PostgreSQL setup **
NFO ==> Validating settings in POSTGRESQL_*env vars..
INFO ==> Initializing PostgreSQL database...
INFO ==> postgresql.conf file not detected. Generating it...
INFO ==> pg_hba.conf file not detected. Generating it...
INFO ==> Deploying PostgreSQL with persisted data...
INFO ==> Configuring replication parameters
INFO ==> Loading custom scripts...
INFO ==> Enabling remote connections
INFO ==> Stopping PostgreSQL...
INFO ==>** PostgreSQL setup finished! **
INFO ==>** Starting PostgreSQL **
[1] FATAL: database files are incompatible with server
[1] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 11.3.
```
In this case, you should migrate the data from the old chart to the new one following an approach similar to that described in [this section](https://www.postgresql.org/docs/current/upgrading.html#UPGRADING-VIA-PGDUMPALL) from the official documentation. Basically, create a database dump in the old chart, move and restore it in the new one.
### 4.0.0
This chart will use by default the Bitnami PostgreSQL container starting from version `10.7.0-r68`. This version moves the initialization logic from node.js to bash. This new version of the chart requires setting the `POSTGRES_PASSWORD` in the slaves as well, in order to properly configure the `pg_hba.conf` file. Users from previous versions of the chart are advised to upgrade immediately.
IMPORTANT: If you do not want to upgrade the chart version then make sure you use the `10.7.0-r68` version of the container. Otherwise, you will get this error
```
The POSTGRESQL_PASSWORD environment variable is empty or not set. Set the environment variable ALLOW_EMPTY_PASSWORD=yes to allow the container to be started with blank passwords. This is recommended only for development
```
### 3.0.0
This releases make it possible to specify different nodeSelector, affinity and tolerations for master and slave pods.
It also fixes an issue with `postgresql.master.fullname` helper template not obeying fullnameOverride.
#### Breaking changes
-`affinty` has been renamed to `master.affinity` and `slave.affinity`.
-`tolerations` has been renamed to `master.tolerations` and `slave.tolerations`.
-`nodeSelector` has been renamed to `master.nodeSelector` and `slave.nodeSelector`.
### 2.0.0
In order to upgrade from the `0.X.X` branch to `1.X.X`, you should follow the below steps:
- Obtain the service name (`SERVICE_NAME`) and password (`OLD_PASSWORD`) of the existing postgresql chart. You can find the instructions to obtain the password in the NOTES.txt, the service name can be obtained by running
```console
$kubectl get svc
```
- Install (not upgrade) the new version
```console
$helm repo update
$helm install--name my-release stable/postgresql
```
- Connect to the new pod (you can obtain the name by running `kubectl get pods`):
```console
$kubectl exec-it NAME bash
```
- Once logged in, create a dump file from the previous database using `pg_dump`, for that we should connect to the previous postgresql chart:
If you don't want to provide the whole configuration file and only specify certain parameters, you can copy here your extended `.conf` files.
These files will be injected as a config maps and add/overwrite the default configuration using the `include_dir` directive that allows settings to be loaded from files other than the default `postgresql.conf`.
More info in the [bitnami-docker-postgresql README](https://github.com/bitnami/bitnami-docker-postgresql#configuration-file).
{{ if and (.Values.networkPolicy.enabled) (not .Values.networkPolicy.allowExternal) }}
Note: Since NetworkPolicy is enabled, only pods with label {{ template "postgresql.fullname" . }}-client=true" will be able to connect to this PostgreSQL cluster.
{{- end }}
To connect to your database from outside the cluster execute the following commands:
{{- if contains "NodePort" .Values.service.type }}
export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
{{ if (include "postgresql.password" . ) }}PGPASSWORD="$POSTGRES_PASSWORD" {{ end }}psql --host 127.0.0.1 -U {{ .Values.postgresqlUsername }}{{- if .Values.postgresqlDatabase }} -d {{ .Values.postgresqlDatabase }}{{- end }} -p {{ template "postgresql.port" . }}
{{- end }}
{{- if and (contains "bitnami/" .Values.image.repository) (not (.Values.image.tag | toString | regexFind "-r\\d+$|sha256:")) }}
WARNING: Rolling tag detected ({{ .Values.image.repository }}:{{ .Values.image.tag }}), please note that it is strongly recommended to avoid using rolling tags in a production environment.
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap}}
-name:postgresql-extended-config
mountPath:/bitnami/postgresql/conf/conf.d/
{{- end}}
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
-name:postgresql-config
configMap:
name:{{template "postgresql.configurationCM" .}}
{{- end}}
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap}}
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
{{- $database:= required "In order to enable metrics you need to specify a database (.Values.postgresqlDatabase or .Values.global.postgresql.postgresqlDatabase)" (include "postgresql.database" .)}}
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
-name:postgresql-config
configMap:
name:{{template "postgresql.configurationCM" .}}
{{- end}}
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap}}
Congratulations. You have just deployed JFrog Artifactory HA!
{{- if and (not .Values.artifactory.masterKeySecretName) (eq .Values.artifactory.masterKey "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF") }}
3. Manage Artifactory license through the {{ .Values.artifactory.license.secret }} secret ONLY!
Since the artifactory license(s) is managed with a secret ({{ .Values.artifactory.license.secret }}), any change through the Artifactory UI might not be saved!
{{- else }}
3. Add HA licenses to activate Artifactory HA through the Artifactory UI
NOTE: Each Artifactory node requires a valid license. See https://www.jfrog.com/confluence/display/RTF/HA+Installation+and+Setup for more details.
{{- end }}
{{ if or .Values.artifactory.primary.javaOpts.jmx.enabled .Values.artifactory.node.javaOpts.jmx.enabled }}
JMX configuration:
{{- if not (contains "LoadBalancer" .Values.artifactory.service.type) }}
If you want to access JMX from you computer with jconsole, you should set ".Values.artifactory.service.type=LoadBalancer" !!!
{{ end }}
1. Get the Artifactory service IP:
{{- if .Values.artifactory.primary.javaOpts.jmx.enabled }}
{{- if and .Release.IsUpgrade .Values.postgresql.enabled}}
databaseUpgradeReady:{{required "\n\n*********\nIMPORTANT:UPGRADE FAILED to prevent data loss!\nReview CHANGELOG.md (https://github.com/jfrog/charts/blob/master/stable/artifactory-ha/CHANGELOG.md) and prepare PostgreSQL DB migration before upgrading.\nOnce ready,explicitly pass 'databaseUpgradeReady=yes' to upgrade and complete migration after server starts!\n" .Values.databaseUpgradeReady | quote}}
externalUrl: {{ required "artifactory.replicator.publicUrl is required when artifactory.replicator.enabled is true" .Values.artifactory.replicator.publicUrl }}
## You may also use existing shared claims for the data and backup storage. This allows storage (NAS for example) to be used for Data and Backup dirs which are safe to share across multiple artifactory nodes.
## You may specify numberOfExistingClaims to indicate how many of these existing shared claims to mount. (Default = 1)
## Create PVCs with ReadWriteMany that match the naming convetions:
## Note: While you need two PVC fronting two PVs, multiple PVs can be attached to the same storage in many cases allowing you to share an underlying drive.
## Need to have the following set
existingSharedClaim:
enabled: false
numberOfExistingClaims: 1
## Should be a child directory of {{ .Values.artifactory.persistence.mountPath }}
**NOTE:** If using artifactory or nginx service type `LoadBalancer`, it might take a few minutes for JFrog Container Registry's public IP to become available.
### Updating JFrog Container Registry
Once you have a new chart version, you can upgrade your deployment with
This will delete your JFrog Container Registry deployment.<br>
**NOTE:** You might have left behind persistent volumes. You should explicitly delete them with
```bash
kubectl delete pvc ...
kubectl delete pv ...
```
## Configuration
The following table lists the **basic** configurable parameters of the JFrog Container Registry chart and their default values.
**NOTE:** All supported parameters are documented in the main [artifactory helm chart](https://github.com/jfrog/charts/tree/master/stable/artifactory).
To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret in the namespace:
Universal Repository Manager supporting all major packaging formats, build tools and CI servers.
## Chart Details
This chart will do the following:
* Deploy JFrog Container Registry
* Deploy an optional Nginx server
* Optionally expose Artifactory with Ingress [Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
## Useful links
Blog: [Herd Trust Into Your Rancher Labs Multi-Cloud Strategy with Artifactory](https://jfrog.com/blog/herd-trust-into-your-rancher-labs-multi-cloud-strategy-with-artifactory/)
## Activate Your Artifactory Instance
Don't have a license? Please send an email to [rancher-jfrog-licenses@jfrog.com](mailto:rancher-jfrog-licenses@jfrog.com) to get it.
All changes to this chart will be documented in this file.
## [8.2.1] - Nov 18, 2019
* Add the option to provide service account annotations (in order to support stuff like https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html)
## [8.2.0] - Nov 18, 2019
* Updated Artifactory version to 6.15.0
## [8.1.11] - Nov 17, 2019
* Do not provide a default master key. Allow it to be auto generated by Artifactory on first startup
## [8.1.10] - Nov 17, 2019
* Fix creation of double slash in nginx artifactory configuration
## [8.1.9] - Nov 14, 2019
* Set explicit `postgresql.postgresqlPassword=""` to avoid helm v3 error
## [8.1.8] - Nov 12, 2019
* Updated Artifactory version to 6.14.1
## [8.1.7] - Nov 9, 2019
* Additional documentation for masterKey
## [8.1.6] - Nov 10, 2019
* Update PostgreSQL chart version to 7.0.1
* Use formal PostgreSQL configuration format
## [8.1.5] - Nov 8, 2019
* Add support `artifactory.service.loadBalancerSourceRanges` for whitelisting when setting `artifactory.service.type=LoadBalancer`
## [8.1.4] - Nov 6, 2019
* Add support for any type of environment variable by using `extraEnvironmentVariables` as-is
## [8.1.3] - Nov 6, 2019
* Add nodeselector support for Postgresql
## [8.1.2] - Nov 5, 2019
* Add support for the aws-s3-v3 filestore, which adds support for pod IAM roles
## [8.1.1] - Nov 4, 2019
* When using `copyOnEveryStartup`, make sure that the target base directories are created before copying the files
## [8.1.0] - Nov 3, 2019
* Updated Artifactory version to 6.14.0
## [8.0.1] - Nov 3, 2019
* Make sure the artifactory pod exits when one of the pre-start stages fail
## [8.0.0] - Oct 27, 2019
**IMPORTANT - BREAKING CHANGES!**<br>
**DOWNTIME MIGHT BE REQUIRED FOR AN UPGRADE!**
* If this is a new deployment or you already use an external database (`postgresql.enabled=false`), these changes **do not affect you**!
* If this is an upgrade and you are using the default PostgreSQL (`postgresql.enabled=true`), must use the upgrade instructions in [UPGRADE_NOTES.md](UPGRADE_NOTES.md)!
* PostgreSQL sub chart was upgraded to version `6.5.x`. This version is **not backward compatible** with the old version (`0.9.5`)!
* Note the following **PostgreSQL** Helm chart changes
* The chart configuration has changed! See [values.yaml](values.yaml) for the new keys used
***PostgreSQL** is deployed as a StatefulSet
* See [PostgreSQL helm chart](https://hub.helm.sh/charts/stable/postgresql) for all available configurations
## [7.18.3] - Oct 24, 2019
* Change the preStartCommand to support templating
## [7.18.2] - Oct 21, 2019
* Add support for setting `artifactory.labels`
* Add support for setting `nginx.labels`
## [7.18.1] - Oct 10, 2019
* Updated Artifactory version to 6.13.1
## [7.18.0] - Oct 7, 2019
* Updated Artifactory version to 6.13.0
## [7.17.5] - Sep 24, 2019
* Option to skip wait-for-db init container with '--set waitForDatabase=false'
## [7.17.4] - Sep 11, 2019
* Updated Artifactory version to 6.12.2
## [7.17.3] - Sep 9, 2019
* Updated Artifactory version to 6.12.1
## [7.17.2] - Aug 22, 2019
* Fix the nginx server_name directive used with ingress.hosts
## [7.17.1] - Aug 21, 2019
* Enable the Artifactory container's liveness and readiness probes
## [7.17.0] - Aug 21, 2019
* Updated Artifactory version to 6.12.0
## [7.16.11] - Aug 14, 2019
* Updated Artifactory version to 6.11.6
## [7.16.10] - Aug 11, 2019
* Fix Ingress routing and add an example
## [7.16.9] - Aug 5, 2019
* Do not mount `access/etc/bootstrap.creds` unless user specifies a custom password or secret (Access already generates a random password if not provided one)
* If custom `bootstrap.creds` is provided (using keys or custom secret), prepare it with an init container so the temp file does not persist
## [7.16.8] - Aug 4, 2019
* Improve binarystore config
1. Convert to a secret
2. Move config to values.yaml
3. Support an external secret
## [7.16.7] - Jul 29, 2019
* Don't create the nginx configmaps when nginx.enabled is false
## [7.16.6] - Jul 24, 2019
* Simplify nginx setup and shorten initial wait for probes
## [7.16.5] - Jul 22, 2019
* Change Ingress API to be compatible with recent kubernetes versions
## [7.16.4] - Jul 22, 2019
* Updated Artifactory version to 6.11.3
## [7.16.3] - Jul 11, 2019
* Add ingress.hosts to the Nginx server_name directive when ingress is enabled to help with Docker repository sub domain configuration
## [7.16.2] - Jul 3, 2019
* Fix values key in reverse proxy example
## [7.16.1] - Jul 1, 2019
* Updated Artifactory version to 6.11.1
## [7.16.0] - Jun 27, 2019
* Update Artifactory version to 6.11 and add restart to Artifactory when bootstrap.creds file has been modified
## [7.15.8] - Jun 27, 2019
* Add the option for changing nginx config using values.yaml and remove outdated reverse proxy documentation
## [7.15.6] - Jun 24, 2019
* Update chart maintainers
## [7.15.5] - Jun 24, 2019
* Change Nginx to point to the artifactory externalPort
## [7.15.4] - Jun 23, 2019
* Add the option to provide an IP for the access-admin endpoints
## [7.15.3] - Jun 23, 2019
* Add values files for small, medium and large installations
## [7.15.2] - Jun 20, 2019
* Add missing terminationGracePeriodSeconds to values.yaml
## [7.15.1] - Jun 19, 2019
* Updated Artifactory version to 6.10.4
## [7.15.0] - Jun 17, 2019
* Use configmaps for nginx configuration and remove nginx postStart command
## [7.14.8] - Jun 18, 2019
* Add the option to provide additional ingress rules
## [7.14.7] - Jun 14, 2019
* Updated readme with improved external database setup example
## [7.14.6] - Jun 11, 2019
* Updated Artifactory version to 6.10.3
* Updated installer-info template
## [7.14.5] - Jun 6, 2019
* Updated Google Cloud Storage API URL and https settings
## [7.14.4] - Jun 5, 2019
* Delete the db.properties file on Artifactory startup
## [7.14.3] - Jun 3, 2019
* Updated Artifactory version to 6.10.2
## [7.14.2] - May 21, 2019
* Updated Artifactory version to 6.10.1
## [7.14.1] - May 19, 2019
* Fix missing logger image tag
## [7.14.0] - May 7, 2019
* Updated Artifactory version to 6.10.0
## [7.13.21] - May 5, 2019
* Add support for setting `artifactory.async.corePoolSize`
### Deploying Artifactory with embedded Derby database
By default, this chart deploys Artifactory with PostgreSQL (running in a separate pod).
It's possible to deploy Artifactory without PostgreSQL (or any other external database), which will default to the embedded [Derby database](https://db.apache.org/derby/).
Artifactory will start with it's embedded Derby database.
### Deploying Artifactory with replicator
The [Artifactory replicator](https://www.jfrog.com/confluence/display/RTF/Replicator) is used with an [Enterprise Plus](https://www.jfrog.com/confluence/display/EP/Welcome+to+JFrog+Enterprise+Plus) license.
```bash
## Artifactory replicator is disabled by default. When the replicator is enabled, the replicator.publicUrl parameter is required. To enable it use the following:
### Deploying Artifactory for small/medium/large instllations
In the chart directory, we have added three values files, one for each installation type - small/medium/large. These values files are recommendations for setting resources requests and limits for your installation. The values are derived from the following [documentation](https://www.jfrog.com/confluence/display/EP/Installing+on+Kubernetes#InstallingonKubernetes-Systemrequirements). You can find them in the corresponding chart directory - values-small.yaml, values-medium.yaml and values-large.yaml
### Accessing Artifactory
**NOTE:** It might take a few minutes for Artifactory's public IP to become available.
Follow the instructions outputted by the install command to get the Artifactory IP to access it.
### Updating Artifactory
Once you have a new chart version, you can update your deployment with
This will apply any configuration changes on your existing deployment.
### Artifactory memory and CPU resources
The Artifactory Helm chart comes with support for configured resource requests and limits to Artifactory, Nginx and PostgreSQL. By default, these settings are commented out.
It is **highly** recommended to set these so you have full control of the allocated resources and limits.
Artifactory java memory parameters can (and should) also be set to match the allocated resources with `artifactory.javaOpts.xms` and `artifactory.javaOpts.xmx`.
```bash
# Example of setting resource requests and limits to all pods (including passing java memory settings to Artifactory)
Get more details on configuring Artifactory in the [official documentation](https://www.jfrog.com/confluence/).
### Artifactory storage
When using an enterprise license. Artifactory supports a wide range of storage back ends. You can see more details on [Artifactory Filestore options](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore)
In this chart, you set the type of storage you want with `artifactory.persistence.type` and pass the required configuration settings.
The default storage in this chart is the `file-system` replication, where the data is replicated to all nodes.
#### NFS
To use an NFS server as your cluster's storage, you need to
- Setup an NFS server. Get its IP as `NFS_IP`
- Create a `data` and `backup` directories on the NFS exported directory with write permissions to all
- Pass NFS parameters to `helm install` and `helm upgrade`
```bash
...
--set artifactory.persistence.type=nfs \
--set artifactory.persistence.nfs.ip=${NFS_IP}\
...
```
#### Google Storage
To use a Google Storage bucket as the cluster's filestore. See [Google Storage Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-GoogleStorageBinaryProvider)
- Pass Google Storage parameters to `helm install` and `helm upgrade`
**NOTE** Keep in mind that when using the `aws-s3` persistence type, you will not be able to provide an IAM on the pod level.
In order to grant permissions to Artifactory using an IAM role, you will have to attach the said IAM role to the machine(s) on which Artifactory is running.
This is due to the fact that the `aws-s3` template uses the `JetS3t` library to interact with AWS. If you want to grant an IAM role at the pod level, see the `AWS S3 Vs` section.
To use an AWS S3 bucket as the cluster's filestore. See [S3 Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-S3BinaryProvider)
- Pass AWS S3 parameters to `helm install` and `helm upgrade`
**NOTE:** Make sure S3 `endpoint` and `region` match. See [AWS documentation on endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html)
#### AWS S3 V3
To use an AWS S3 bucket as the cluster's filestore and access it with the official AWS SDK, See [S3 Official SDK Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-AmazonS3OfficialSDKTemplate).
This filestore template uses the official AWS SDK, unlike th`aws-s3` implementation that uses the `JetS3t` library.
Use this template if you want to attach an IAM role to the Artifactory pod directly (as opposed to attaching it to the machine/s that Artifactory will run on).
**NOTE** This will have to be combined with a k8s mechanism for attaching IAM roles to pods, like [kube2iam](https://github.com/helm/charts/tree/master/stable/kube2iam) or anything similar.
- Pass AWS S3 V3 parameters and the annotation pointing to the IAM role (when using an IAM role. this is kube2iam specific and may vary depending on the implementation) to `helm install` and `helm upgrade`
To use Azure Blob Storage as the cluster's filestore. See [Azure Blob Storage Binary Provider](https://www.jfrog.com/confluence/display/RTF/Configuring+the+Filestore#ConfiguringtheFilestore-AzureBlobStorageClusterBinaryProvider)
- Pass Azure Blob Storage parameters to `helm install` and `helm upgrade`
* To use a persistent volume claim as cache dir together with Azure Blob Storage, additionally pass the following parameters to `helm install` and `helm upgrade` (make sure `mountPath` and `cacheProviderDir` point to the same location)
**NOTE:** This method is relevant for initial deployment only! Once Artifactory is deployed, you should not keep passing these parameters as the license is already persisted into Artifactory's storage (they will be ignored).
Updating the license should be done via Artifactory UI or REST API.
If you want to keep managing the artifactory license using the same method, you can use the copyOnEveryStartup example shown in the values.yaml file
##### Create the secret as part of the helm release
**NOTE:** This method is relevant for initial deployment only! Once Artifactory is deployed, you should not keep passing these parameters as the license is already persisted into Artifactory's storage (they will be ignored).
Updating the license should be done via Artifactory UI or REST API.
If you want to keep managing the artifactory license using the same method, you can use the copyOnEveryStartup example shown in the values.yaml file
### Configure NetworkPolicy
NetworkPolicy specifies what ingress and egress is allowed in this namespace. It is encouraged to be more specific whenever possible to increase security of the system.
In the `networkpolicy` section of values.yaml you can specify a list of NetworkPolicy objects.
For podSelector, ingress and egress, if nothing is provided then a default `- {}` is applied which is to allow everything.
A full (but very wide open) example that results in 2 NetworkPolicy objects being created:
```yaml
networkpolicy:
# Allows all ingress and egress to/from artifactory.
-name:artifactory
podSelector:
matchLabels:
app:artifactory
egress:
-{}
ingress:
-{}
# Allows connectivity from artifactory pods to postgresql pods, but no traffic leaving postgresql pod.
-name:postgres
podSelector:
matchLabels:
app:postgresql
ingress:
-from:
-podSelector:
matchLabels:
app:artifactory
```
### Artifactory JMX Configuration
** You can see some information about the exposed MBeans here - https://www.jfrog.com/confluence/display/RTF/Artifactory+JMX+MBeans
Enable JMX in your deployment:
```bash
helm install--name artifactory \
--set artifactory.javaOpts.jmx.enabled=true\
jfrog/artifactory
```
This will enable access to Artifactory with JMX on the default port (9010).
** You have the option to change the port by setting ```artifactory.javaOpts.jmx.port``` to your choice of port
In order to connect to Artifactory using JMX with jconsole (or any similar tool) installed on your computer, follow the following steps:
1. Enable JMX as described above and Change the Artifactory service to be of type LoadBalancer:
```bash
helm install--name artifactory \
--set artifactory.javaOpts.jmx.enabled=true\
--set artifactory.service.type=LoadBalancer \
jfrog/artifactory
```
2. The default setting for java.rmi.server.hostname is the service name (this is also configurable with ```artifactory.javaOpts.jmx.host```).
So in order to connect to Artifactory with jconsole you should map the Artifactory kuberentes service IP to the service name using your hosts file as such:
3. Launch jconsole with the service address and port:
```bash
jconsole artifactory-<release-name>:<jmx-port>
```
### Access creds. bootstraping
**IMPORTANT:** Bootsrapping access creds. will automatically trigger a restart to the Artifactory pod and will allow access for the user `access-admin` from certain IP's.
* User guide to [bootstrap Artifactory Access credentials](https://www.jfrog.com/confluence/display/ACC/Configuring+Access)
1. Create `access-creds-values.yaml` and provide the IP (By default 127.0.0.1) and password:
3. Restart Artifactory Pod (`Kubectl delete pod <pod_name>`)
### Bootstrapping Artifactory
**IMPORTANT:** Bootstrapping Artifactory needs license. Pass license as shown in above section.
* User guide to [bootstrap Artifactory Global Configuration](https://www.jfrog.com/confluence/display/RTF/Configuration+Files#ConfigurationFiles-BootstrappingtheGlobalConfiguration)
* User guide to [bootstrap Artifactory Security Configuration](https://www.jfrog.com/confluence/display/RTF/Configuration+Files#ConfigurationFiles-BootstrappingtheSecurityConfiguration)
1. Create `bootstrap-config.yaml` with artifactory.config.import.xml and security.import.xml as shown below:
There are cases where you will want to use an external PostgreSQL with a different database name e.g. `my-artifactory-db`, then you need set a custom PostgreSQL connection URL, where `my-artifactory-db` is the name of the database.
**NOTE:** You must set `postgresql.enabled=false` in order for the chart to use the `database.*` parameters. Without it, they will be ignored!
#### Using pre-existing Kubernetes Secret
If you store your database credentials in a pre-existing Kubernetes `Secret`, you can specify them via `database.secrets` instead of `database.user` and `database.password`:
```bash
# Create a secret containing the database credentials
There are cases where a special, unsupported init processes is needed like checking something on the file system or testing something before spinning up the main container.
For this, there is a section for writing a custom init container in the [values.yaml](values.yaml). By default it's commented out
```yaml
artifactory:
## Add custom init containers
customInitContainers:|
## Init containers template goes here ##
```
### Custom sidecar containers
There are cases where an extra sidecar container is needed. For example monitoring agents or log collection.
For this, there is a section for writing a custom sidecar container in the [values.yaml](values.yaml). By default it's commented out
```yaml
artifactory:
## Add custom sidecar containers
customSidecarContainers:|
## Sidecar containers template goes here ##
```
### Custom volumes
If you need to use a custom volume in a custom init or sidecar container, you can use this option.
For this, there is a section for defining custom volumes in the [values.yaml](values.yaml). By default it's commented out
```yaml
artifactory:
## Add custom volumes
customVolumes:|
## Custom volume comes here ##
```
You can configure the sidecar to run as a custom user if needed by setting the following in the container template
```yaml
# Example of running container as root (id 0)
securityContext:
runAsUser:0
fsGroup:0
```
### Add Artifactory User Plugin during installation
If you need to add [Artifactory User Plugin](https://github.com/jfrog/artifactory-user-plugins), you can use this option.
Create a secret with [Artifactory User Plugin](https://github.com/jfrog/artifactory-user-plugins) by following command:
Alternatively, you may be in a situation in which you would like to create a secret in a Helm chart that depends on this chart. In this scenario, the name of the secret is likely dynamically generated via template functions, so passing a statically named secret isn't possible. In this case, the chart supports evaluating strings as templates via the [`tpl`](https://helm.sh/docs/charts_tips_and_tricks/#using-the-tpl-function) function - simply pass the raw string containing the templating language used to name your secret as a value instead by adding the following to your chart's `values.yaml` file:
```yaml
artifactory:# Name of the artifactory dependency
artifactory:
userPluginSecrets:
-'{{template"my-chart.fullname".}}'
```
NOTE: By defining userPluginSecrets, this overrides any pre-defined plugins from the container image that are stored in /tmp/plugins. At this time [artifactory-pro:6.9.0](https://bintray.com/jfrog/artifactory-pro) is distributed with `internalUser.groovy` plugin. If you need this plugin in addition to your user plugins, you should include these additional plugins as part of your userPluginSecrets.
## Configuration
The following table lists the configurable parameters of the artifactory chart and their default values.
| `artifactory.userPluginSecrets` | Array of secret names for Artifactory user plugins | |
| `artifactory.license.licenseKey` | Artifactory license key. Providing the license key as a parameter will cause a secret containing the license key to be created as part of the release. Use either this setting or the license.secret and license.dataKey. If you use both, the latter will be used. | |
| `artifactory.license.secret` | Artifactory license secret name | |
| `artifactory.license.dataKey`| Artifactory license secret data key | |
| `artifactory.service.name`| Artifactory service name to be set in Nginx configuration | `artifactory` |
| `artifactory.service.type`| Artifactory service type | `ClusterIP` |
| `artifactory.service.loadBalancerSourceRanges`| Artifactory service array of IP CIDR ranges to whitelist (only when service type is LoadBalancer) | |
| `artifactory.service.annotations` | Artifactory service annotations | `{}` |
| `artifactory.externalPort` | Artifactory service external port | `8081` |
| `artifactory.internalPort` | Artifactory service internal port | `8081` |
| `artifactory.internalPortReplicator` | Replicator service internal port | `6061` |
| `artifactory.externalPortReplicator` | Replicator service external port | `6061` |
| `artifactory.livenessProbe.initialDelaySeconds` | Delay before liveness probe is initiated | 180 |
| `artifactory.livenessProbe.periodSeconds` | How often to perform the probe | 10 |
| `artifactory.livenessProbe.timeoutSeconds` | When the probe times out | 10 |
| `artifactory.livenessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed. | 1 |
| `artifactory.livenessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | 10 |
| `artifactory.masterKey` | Artifactory masterkey. A 128-Bit key size (hexadecimal encoded) string (32 hex characters). Can be generated with `openssl rand -hex 16`.
NOTE: This key is generated only once and cannot be updated once created | `` |
| `artifactory.masterKeySecretName` | Artifactory Master Key secret name | |
| `artifactory.accessAdmin.ip` | Artifactory access-admin ip to be set upon startup, can use (*) for 0.0.0.0| 127.0.0.1 |
| `artifactory.accessAdmin.password` | Artifactory access-admin password to be set upon startup| |
| `artifactory.accessAdmin.secret` | Artifactory access-admin secret name | |
| `artifactory.accessAdmin.dataKey` | Artifactory access-admin secret data key | |
| `artifactory.preStartCommand` | Command to run before entrypoint starts | |
| `artifactory.postStartCommand` | Command to run after container starts | |
| `artifactory.extraEnvironmentVariables` | Extra environment variables to pass to Artifactory. Supports evaluating strings as templates via the [`tpl`](https://helm.sh/docs/charts_tips_and_tricks/#using-the-tpl-function) function. See [documentation](https://www.jfrog.com/confluence/display/RTF/Installing+with+Docker#InstallingwithDocker-SupportedEnvironmentVariables) | |
| `artifactory.readinessProbe.enabled` | would you like a readinessProbe to be enabled | `true` |
| `artifactory.readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | 60 |
| `artifactory.readinessProbe.periodSeconds` | How often to perform the probe | 10 |
| `artifactory.readinessProbe.timeoutSeconds` | When the probe times out | 10 |
| `artifactory.readinessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed. | 1 |
| `artifactory.readinessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | 10 |
| `artifactory.deleteDBPropertiesOnStartup` | Whether to delete the ARTIFACTORY_HOME/etc/db.properties file on startup. Disabling this will remove the ability for the db.properties to be updated with any DB-related environment variables change (e.g. DB_HOST, DB_URL) | `true` |
| `artifactory.copyOnEveryStartup` | List of files to copy on startup from source (which is absolute) to target (which is relative to ARTIFACTORY_HOME | |
| `artifactory.persistence.size` | Artifactory persistence or local volume size | `20Gi` |
| `artifactory.persistence.binarystoreXml` | Artifactory binarystore.xml template | See `values.yaml` |
| `artifactory.persistence.customBinarystoreXmlSecret` | A custom Secret for binarystore.xml | `` |
| `artifactory.persistence.maxCacheSize` | The maximum storage allocated for the cache in bytes. | `50000000000` |
| `artifactory.persistence.cacheProviderDir` | the root folder of binaries for the filestore cache. If the value specified starts with a forward slash ("/") it is considered the fully qualified path to the filestore folder. Otherwise, it is considered relative to the *baseDataDir*. | `cache` |
| `artifactory.persistence.type` | Artifactory HA storage type | `file-system` |
| `artifactory.persistence.redundancy` | Artifactory HA storage redundancy | `3` |
| `artifactory.persistence.nfs.ip` | NFS server IP | |
| `artifactory.persistence.nfs.haDataMount` | NFS data directory | `/data` |
| `artifactory.persistence.awsS3.refreshCredentials` | AWS S3 renew credentials on expiration | `true` (When roleName is used, this parameter will be set to true) |
| `artifactory.persistence.awsS3.httpsOnly` | AWS S3 https access to the bucket only | `true` |
| `artifactory.persistence.awsS3.testConnection` | AWS S3 test connection on start up | `false` |
| `artifactory.persistence.awsS3.s3AwsVersion` | AWS S3 signature version | `AWS4-HMAC-SHA256` |
| `artifactory.persistence.awsS3V3.testConnection` | AWS S3 test connection on start up | `false` |
| `artifactory.persistence.awsS3V3.signatureExpirySeconds` | AWS S3 Validity period in seconds for signed URLs | `300` |
| `artifactory.persistence.awsS3V3.cloudFrontDomainName` | AWS CloudFront domain name | See https://www.jfrog.com/confluence/display/RTF/Direct+Cloud+Storage+Download#DirectCloudStorageDownload-UsingCloudFront(Optional)|
| `artifactory.persistence.awsS3V3.cloudFrontKeyPairId` | AWS CloudFront key pair ID | See https://www.jfrog.com/confluence/display/RTF/Direct+Cloud+Storage+Download#DirectCloudStorageDownload-UsingCloudFront(Optional)|
| `artifactory.persistence.awsS3V3.cloudFrontPrivateKey` | AWS CloudFront private key | See https://www.jfrog.com/confluence/display/RTF/Direct+Cloud+Storage+Download#DirectCloudStorageDownload-UsingCloudFront(Optional)|
| `artifactory.javaOpts.corePoolSize` | The number of async processes that can run in parallel - https://jfrog.com/knowledge-base/how-do-i-tune-artifactory-for-heavy-loads/ | `8` |
| `ingress.defaultBackend.enabled` | If true, the default `backend` will be added using serviceName and servicePort | `true` |
| `ingress.annotations` | Ingress annotations, which are written out if annotations section exists in values. Everything inside of the annotations section will appear verbatim inside the resulting manifest. See `Ingress annotations` section below for examples of how to leverage the annotations, specifically for how to enable docker authentication. | |
| `ingress.additionalRules` | Ingress additional rules to be added to the Artifactory ingress. | `[]` |
| `nginx.name` | Nginx name | `nginx` |
| `nginx.enabled` | Deploy nginx server | `true` |
If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [cert-manager](https://github.com/jetstack/cert-manager)), please refer to the documentation for that mechanism.
To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret in the namespace:
Include the secret's name, along with the desired hostnames, in the Artifactory Ingress TLS section of your custom `values.yaml` file:
```yaml
ingress:
## If true, Artifactory Ingress will be created
##
enabled: true
## Artifactory Ingress hostnames
## Must be provided if Ingress is enabled
##
hosts:
- artifactory.domain.com
annotations:
kubernetes.io/tls-acme: "true"
## Artifactory Ingress TLS configuration
## Secrets must be manually created in the namespace
##
tls:
- secretName: artifactory-tls
hosts:
- artifactory.domain.com
```
### Ingress annotations
This example specifically enables Artifactory to work as a Docker Registry using the Repository Path method. See [Artifactory as Docker Registry](https://www.jfrog.com/confluence/display/RTF/Getting+Started+with+Artifactory+as+a+Docker+Registry) documentation for more information about this setup.
