Details on the Lightup Self-hosted deployment model.
You can deploy Lightup Self-hosted to an existing self-managed or AWS EKS-managed Kubernetes cluster, using the following procedure.
To get started, contact [email protected].
You will receive a Lightup token in email.
Before deployment, you'll need to provide Lightup with more information:
- The e-mail address of the initial admin user, if it's not the same as the one that's making the request. This should be provided before the deployment.
- The URL or IP address you'll use to access the cluster. This can be supplied later but you won't be able to access the cluster until Lightup has this info.
There are also a number of prerequisite steps.
Outbound connectivity— Your system instance must always have access to the following internet services for the proper functioning of Lightup. You should modify your firewall rules if you cannot access any of these services.
Service Domains to whitelist Replicated (replicated.com): Lightup application software is packaged and licensed using Replicated. The application bundle (Kubernetes binaries, Docker containers, license file) are pulled from Replicated during the installation sequence and subsequent upgrades. - *.replicated.com (enables Upstream Docker images via proxy.replicated.com. The on-prem docker client uses a license ID to authenticate to proxy.replicated.com. This domain is owned by Replicated, Inc., headquartered in Los Angeles, CA.)
- quay.io (source of replicated images for releases)
- *.gcr.io (source of replicated images for releases)
- *.docker.io (source of replicated images for releases)
- k8s.kurl.sh (source of Kubernetes cluster installation scripts and artifacts: an application identifier is sent in a URL path, and bash scripts and binary executables are served from kurl.sh. This domain is owned by Replicated, Inc., headquartered in Los Angeles, CA)
- amazonaws.com (source of tar.gz: packages are downloaded from Amazon S3. The IP ranges to whitelist for accessing these can be scraped dynamically from the AWS IP Address Ranges documentation.)
Datadog: Lightup uses Datadog for container logging, metric monitoring and Kubernetes pod health monitoring *.datadoghq.com (enables Lightup monitoring) Lightup AWS Services: Lightup leverages a dedicated single-tenant service for install and upgrade requirements. *.lightup.ai (enables Lightup system updates and calls)
A supported Kubernetes version— We currently support versions 1.24 through 1.27.
AWS EKS— If you’re using AWS EKS, make sure that the following add-ons or equivalent have been installed:
Sufficient cluster resources— You need a minimum of 4 vCPUs / 16 GB memory per node and a minimum total resources across all nodes of 8 vCPUs, 64GB RAM.
- Install Postgres Server 14.
- Set up regular snapshots— we recommend daily backups.
- When your Postgres instance is ready, log in and complete the following steps:
a. Make note of the Postgres host, TCP port, username and password - you'll need them during the next installation step (when you bootstrap the Lightup data plane).
b. In each database, set max_connection >= 500 and run the following code:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements; SELECT * FROM pg_stat_statements LIMIT 1; CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; SELECT uuid_generate_v4();
- Connect to a VM / laptop / server that has access to the Kubernetes cluster and can run
- Make sure kubectl, curl, gpg and tar are installed.
- Make sure that the kubectl context points to the cluster where you are deploying Lightup. For help, see Kubernetes page, Configure Access to Multiple Clusters.
- Run the following command, using the tla and token values from Lightup:
curl -H 'Cache-Control: no-cache' -L \ https://s3.us-west-2.amazonaws.com/www.lightup.ai/launch_lightup.sh | \ LIGHTUP_TLA=<tla> LIGHTUP_TOKEN=<token> bash -s deploy
- Follow the prompts to complete Postgres configuration, entering the values you noted when you set up Postgres.
- Wait for about 10 minutes, then proceed to Step 3: Access the Lightup UI.
Lightup exposes a NodePort on port 30443 that you can use to access the Lightup UI.
If the nodes in your EKS cluster have public IP addresses, then you can access the UI at
https\://<ip-address-or-host-name-of-your-VM>:30443. If the nodes do not have a public IP address or if you want to configure a URL, you can use an AWS Network Load Balancer or an AWS Application Load Balancer to access the UI. Lightup only works with supported domains, so you'll need to provide Lightup support with your IP address / hostname / URL.
The following example shows how you'd access the Lightup UI at
https://lightup.my-company.com using a Network Load Balancer.
Create a certificate for
lightup.my-company.comwith AWS Certificate Manager (ACM).
Verify the certificate with the option to create records in Route 53.
Copy the certificate ARN— you'll need this for the following step.
Update the following manifest for the Kubernetes service that will generate the NLB, and save it as a file named lightup-nlb-service.yaml:
apiVersion: v1 kind: Service metadata: name: lightup-backend annotations: external-dns.alpha.kubernetes.io/hostname: lightup.my-company.com service.beta.kubernetes.io/aws-load-balancer-ssl-cert: YOUR_COPIED_CERTIFICATE_ARN service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: ELBSecurityPolicy-FS-1-2-Res-2020-10 service.beta.kubernetes.io/aws-load-balancer-type: nlb labels: app: backend spec: externalTrafficPolicy: Local loadBalancerSourceRanges: - 0.0.0.0/0 ports: - name: backend port: 443 protocol: TCP targetPort: 8000 selector: app: backend release: backend type: LoadBalancer
Deploy the NLB using kubectl and the YAML file you saved:
kubectl apply -n lightup -f lightup-nlb-service.yaml
Copy the generated NLB's URL.
Create a new Route 53 A record for
lightup.my-company.comto route to the NLB's URL.
If the Lightup application needs to use a singular, consistent IP address to access your datasources, you can configure a NAT gateway for your k8s cluster on any of the following platforms:
Updated 27 days ago