Kubernetes deployment
This guide assumes that all prerequisites have been met. Please visit the corresponding Prerequisites page for your infrastructure provider.
You may also use this guide for deployments to other cloud platforms (e.g. Oracle Kubernetes Engine), however it is up to you to satisfy any prerequisites for those platforms. Use at your own risk.
Deploy Tower
Create a namespace
Create a namespace to group the Tower resources within your K8s cluster.
-
Create the namespace (e.g.
tower-nf
):kubectl create namespace tower-nf
-
Switch to the namespace:
kubectl config set-context --current --namespace=tower-nf
Configure container registry credentials
Nextflow Tower is distributed as a collection of Docker containers available through the Seqera Labs
container registry cr.seqera.io
. Contact support to get your container access credentials. Once you have received your credentials, grant your cluster access to the registry using these steps:
-
Retrieve the
name
andsecret
values from the JSON file you received from Seqera Labs support. -
Create a Kubernetes Secret, using the
name
andsecret
retrieved in step 1, with this command:kubectl create secret docker-registry cr.seqera.io \
--docker-server=cr.seqera.io \
--docker-username='/\<YOUR NAME\>/' \
--docker-password='<YOUR SECRET>'Note: The credential
name
contains a dollar$
character. To prevent the Linux shell from interpreting this value as an environment variable, wrap it in single quotes. -
The following snippet configures the Tower cron service and the Tower frontend and backend to use the Secret created in step 2 (see tower-cron.yml and tower-svc.yml):
imagePullSecrets:
- name: "cr.seqera.io"
This parameter is already included in the templates linked above — if you use a name other than cr.seqera.io
for the Kubernetes Secret, update this value accordingly in the configuration files.
Tower ConfigMap
configmap.yml
"docs/enterprise/_templates/k8s/configmap.yml"
-
Download and configure configmap.yml as per the configuration page.
-
Deploy the configmap to your cluster:
kubectl apply -f configmap.yml
The configmap.yml
manifest includes both tower.env
and tower.yml
. These files are made available to the other containers through volume mounts.
Redis
redis.aks.yml
"docs/enterprise/_templates/k8s/redis.aks.yml"
redis.eks.yml
"docs/enterprise/_templates/k8s/redis.eks.yml"
redis.gke.yml
"docs/enterprise/_templates/k8s/redis.gke.yml"
Download the appropriate manifest for your infrastructure:
Deploy to your cluster:
kubectl apply -f redis.*.yml
You may also be able to use a managed Redis service such as Amazon Elasticache or Google Memorystore, however we do not explicitly support these services, and Tower is not guaranteed to work with them. Use at your own risk.
If you do use an externally managed Redis service, make sure to update configmap.yml
accordingly:
TOWER_REDIS_URL: redis://<redis private IP>:6379
Tower cron service
tower-cron.yml
"docs/enterprise/_templates/k8s/tower-cron.yml"
- Download the manifest:
- Deploy to your cluster:
kubectl apply -f tower-cron.yml
This container will create the required database schema the first time it is instantiated. This process can take a few minutes to complete and must be finished before you instantiate the Tower backend. Make sure this container is in the READY
state before proceeding to the next step.
Tower frontend and backend
tower-svc.yml
"docs/enterprise/_templates/k8s/tower-svc.yml"
Download the manifest:
Deploy to your cluster:
kubectl apply -f tower-svc.yml
Tower ingress
An ingress is used to make Tower publicly accessible, load balance traffic, terminate SSL/TLS, and offer name-based virtual hosting. The included ingress will create an external IP address and forward HTTP traffic to the Tower frontend.
ingress.aks.yml
"docs/enterprise/_templates/k8s/ingress.aks.yml"
ingress.eks.yml
"docs/enterprise/_templates/k8s/ingress.eks.yml"
ingress.gke.yml
"docs/enterprise/_templates/k8s/ingress.gke.yml"
Download the appropriate manifest and configure it according to your infrastructure:
Deploy to your cluster:
kubectl apply -f ingress.*.yml
See the Kubernetes documentation on Ingress for more information. If you don't need to make Tower externally accessible, you can also use a NodePort or a LoadBalancer service to make it accessible within your intranet.
Additionally, see the relevant documentation for configuring an Ingress on each cloud provider:
Check status
Finally, make sure that all services are up and running:
kubectl get pods
Test the application
To make sure that Tower is properly configured, follow these steps:
-
Log in to Tower.
-
Create an organization.
-
Create a workspace within that organization.
-
Create a new Compute Environment. Refer to Compute Environments for detailed instructions.
-
Select Quick Launch from the Launchpad tab in your workspace.
-
Enter the repository URL for the
nf-core/rnaseq
pipeline (https://github.com/nf-core/rnaseq
). -
In the Config profiles dropdown, select the
test
profile. -
In the Pipeline parameters textarea, change the output directory to a sensible location based on your Compute Environment:
# save to S3 bucket
outdir: s3://<your-bucket>/results
# save to scratch directory (Kubernetes)
outdir: /scratch/results -
Select Launch.
You'll be transitioned to the Runs tab for the workflow. After a few minutes, you'll see the progress logs in the Execution log tab for that workflow.
Optional addons
Database console
dbconsole.yml
"docs/enterprise/_templates/k8s/dbconsole.yml"
The included dbconsole.yml can be used to deploy a simple web frontend to the Tower database. It is not required but it can be useful for administrative purposes.
-
Deploy the database console:
kubectl apply -f dbconsole.yml
-
Port-forward the database console to your local machine:
kubectl port-forward deployment/dbconsole 8080:8080
The database console will be available in your browser at
http://localhost:8080
.
High availability
When configuring Tower for high availability, it should be noted that:
-
The
cron
service may only have a single instance -
The
backend
service can be run in multiple replicas -
The
frontend
service is replicable, however in most scenarios it is not necessary