A simple database-backed web application that runs in the public cloud but keeps its data in a private database
This example is part of a suite of examples showing the different ways you can use Skupper to connect services across cloud providers, data centers, and edge sites.
- Overview
- Prerequisites
- Step 1: Install the Skupper command-line tool
- Step 2: Set up your Kubernetes namespaces
- Step 3: Set up your Podman network
- Step 4: Deploy the application
- Step 5: Create your sites
- Step 6: Link your sites
- Step 7: Expose application services
- Step 8: Access the frontend
- Cleaning up
- Summary
- Next steps
- About this example
This example is a simple database-backed web application that shows how you can use Skupper to access a database at a remote site without exposing it to the public internet.
It contains three services:
-
A PostgreSQL database running on a bare-metal or virtual machine in a private data center.
-
A payment-processing service running on Kubernetes in a private data center.
-
A web frontend service running on Kubernetes in the public cloud. It uses the PostgreSQL database and the payment-processing service.
The example uses two Kubernetes namespaces, private
and public
,
to represent the Kubernetes cluster in the private data center and
the cluster in the public cloud. It uses Podman to run the
database.
-
The
kubectl
command-line tool, version 1.15 or later (installation guide) -
Access to at least one Kubernetes cluster, from any provider you choose
This example uses the Skupper command-line tool to deploy Skupper.
You need to install the skupper
command only once for each
development environment.
On Linux or Mac, you can use the install script (inspect it here) to download and extract the command:
curl https://skupper.io/install.sh | sh
The script installs the command under your home directory. It prompts you to add the command to your path if necessary.
For Windows and other installation options, see Installing Skupper.
Skupper is designed for use with multiple Kubernetes namespaces,
usually on different clusters. The skupper
and kubectl
commands use your kubeconfig and current context to
select the namespace where they operate.
Your kubeconfig is stored in a file in your home directory. The
skupper
and kubectl
commands use the KUBECONFIG
environment
variable to locate it.
A single kubeconfig supports only one active context per user. Since you will be using multiple contexts at once in this exercise, you need to create distinct kubeconfigs.
For each namespace, open a new terminal window. In each terminal,
set the KUBECONFIG
environment variable to a different path and
log in to your cluster. Then create the namespace you wish to use
and set the namespace on your current context.
Note: The login procedure varies by provider. See the documentation for yours:
- Minikube
- Amazon Elastic Kubernetes Service (EKS)
- Azure Kubernetes Service (AKS)
- Google Kubernetes Engine (GKE)
- IBM Kubernetes Service
- OpenShift
Public:
export KUBECONFIG=~/.kube/config-public
# Enter your provider-specific login command
kubectl create namespace public
kubectl config set-context --current --namespace public
Private:
export KUBECONFIG=~/.kube/config-private
# Enter your provider-specific login command
kubectl create namespace private
kubectl config set-context --current --namespace private
Open a new terminal window and set the SKUPPER_PLATFORM
environment variable to podman
. This sets the Skupper platform
to Podman for this terminal session.
Use podman network create
to create the Podman network that
Skupper will use.
Use systemctl
to enable the Podman API service.
Podman:
export SKUPPER_PLATFORM=podman
podman network create skupper
systemctl --user enable --now podman.socket
If the systemctl
command doesn't work, you can try the podman system service
command instead:
podman system service --time=0 unix://$XDG_RUNTIME_DIR/podman/podman.sock &
Use kubectl apply
to deploy the frontend and payment processor
on Kubernetes. Use podman run
to start the database on your
local machine.
Note: It is important to name your running container using
--name
to avoid a collision with the container that Skupper
creates for accessing the service.
Note: You must use --network skupper
with the podman run
command.
Public:
kubectl apply -f frontend/kubernetes.yaml
Private:
kubectl apply -f payment-processor/kubernetes.yaml
Podman:
podman run --name database-target --network skupper --detach --rm -p 5432:5432 quay.io/skupper/patient-portal-database
Public:
skupper init
Private:
skupper init --ingress none
Podman:
skupper init --ingress none
Creating a link requires use of two skupper
commands in
conjunction, skupper token create
and skupper link create
.
The skupper token create
command generates a secret token that
signifies permission to create a link. The token also carries the
link details. Then, in a remote site, The skupper link create
command uses the token to create a link to the site
that generated it.
Note: The link token is truly a secret. Anyone who has the token can link to your site. Make sure that only those you trust have access to it.
First, use skupper token create
in site Public to generate the
token. Then, use skupper link create
in site Private to link
the sites.
Public:
skupper token create --uses 2 ~/secret.token
Private:
skupper link create ~/secret.token
Podman:
skupper link create ~/secret.token
If your terminal sessions are on different machines, you may need
to use scp
or a similar tool to transfer the token securely. By
default, tokens expire after a single use or 15 minutes after
creation.
In Private, use skupper expose
to expose the payment processor
service.
In Podman, use skupper service create
and skupper service bind
to expose the database on the Skupper network.
Then, in Public, use skupper service create
to make it
available.
Note: Podman sites do not automatically replicate services
to remote sites. You need to use skupper service create
on
each site where you wish to make a service available.
Private:
skupper expose deployment/payment-processor --port 8080
Podman:
skupper service create database 5432
skupper service bind database host database-target --target-port 5432
Public:
skupper service create database 5432
In order to use and test the application, we need external access to the frontend.
Use kubectl expose
with --type LoadBalancer
to open network
access to the frontend service.
Once the frontend is exposed, use kubectl get service/frontend
to look up the external IP of the frontend service. If the
external IP is <pending>
, try again after a moment.
Once you have the external IP, use curl
or a similar tool to
request the /api/health
endpoint at that address.
Note: The <external-ip>
field in the following commands is a
placeholder. The actual value is an IP address.
Public:
kubectl expose deployment/frontend --port 8080 --type LoadBalancer
kubectl get service/frontend
curl http://<external-ip>:8080/api/health
Sample output:
$ kubectl expose deployment/frontend --port 8080 --type LoadBalancer
service/frontend exposed
$ kubectl get service/frontend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.103.232.28 <external-ip> 8080:30407/TCP 15s
$ curl http://<external-ip>:8080/api/health
OK
If everything is in order, you can now access the web interface by
navigating to http://<external-ip>:8080/
in your browser.
To remove Skupper and the other resources from this exercise, use the following commands.
Public:
skupper delete
kubectl delete service/frontend
kubectl delete deployment/frontend
Private:
skupper delete
kubectl delete deployment/payment-processor
Podman:
skupper delete
podman stop database-target
Check out the other examples on the Skupper website.
This example was produced using Skewer, a library for documenting and testing Skupper examples.
Skewer provides utility functions for generating the README and
running the example steps. Use the ./plano
command in the project
root to see what is available.
To quickly stand up the example using Minikube, try the ./plano demo
command.