Deploying MySQL

The secret must be created before the database is deployed, since it is used during the container startup:

apiVersion: v1
kind: Secret
metadata:
  name: mysql-auth 
type: Opaque
stringData:
  username: visitors-user 
  password: visitors-pass 

When the database and backend deployments use the secret, it is referred to by this name.

For simplicity in this example, the username and password are defaulted to testing values.

You can find the definition for the secret resource in the database.yaml file in this book’s GitHub repository.

Once the secret is in place, use the following manifest to deploy a MySQL instance into Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: visitors
      tier: mysql
  template:
    metadata:
      labels:
        app: visitors
        tier: mysql
    spec:
      containers:
        - name: visitors-mysql
          image: "mysql:5.7"  
          imagePullPolicy: Always
          ports:
            - name: mysql
              containerPort: 3306  
              protocol: TCP
          env:  
            - name: MYSQL_ROOT_PASSWORD
              value: password
            - name: MYSQL_DATABASE
              value: visitors_db
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: mysql-auth 
                  key: username
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-auth 
                  key: password

The deployment name must be unique to the namespace in which it is deployed.

The deployment requires the details of the image to deploy, including its name and hosting repository.

Users must be aware of each port that the image exposes, and must explicitly reference them.

The values used to configure the containers for this specific deployment are passed as environment variables.

The secret provides the values for the database authentication credentials.

Keep in mind the value of the container port, as well as each of the environment variables, as other manifests use these values.

The deployment causes the creation of the MySQL container; however, it does not provide any ingress configuration on how to access it. For that, we will need a service. The following manifest will create a Kubernetes service that provides access to the MySQL deployment:

apiVersion: v1
kind: Service
metadata:
  name: mysql-service  
  labels:
    app: visitors
    tier: mysql
spec:
  clusterIP: None
  ports:
    - port: 3306  
  selector:
    app: visitors
    tier: mysql

As with deployments, service names must be unique in a given namespace. This will also apply to the deployment and services for the backend and frontend components.

The service maps to a port exposed by a deployment, so this value must be the same as in the ports section of the deployment.

Backend

Similar to the MySQL resources, the backend needs both a deployment and a service. However, whereas the database is standalone, the configuration for the backend relies heavily on the values set for the database. While this isn’t an unreasonable requirement, it falls on the user to ensure that the values are consistent across both resources. A single error could result in the backend not being able to communicate with the database. Here’s the manifest to deploy the backend:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: visitors-backend
spec:
  replicas: 1  
  selector:
    matchLabels:
      app: visitors
      tier: backend
  template:
    metadata:
      labels:
        app: visitors
        tier: backend
    spec:
      containers:
        - name: visitors-backend
          image: "jdob/visitors-service:1.0.0"
          imagePullPolicy: Always
          ports:
            - name: visitors
              containerPort: 8000
          env:
            - name: MYSQL_DATABASE  
              value: visitors_db
            - name: MYSQL_SERVICE_HOST  
              value: mysql-service
            - name: MYSQL_USERNAME
              valueFrom:
                secretKeyRef:
                  name: mysql-auth  
                  key: username
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-auth  
                  key: password

Each deployment configuration includes the number of containers it should spawn.

These values must be manually checked to ensure they match up with the values set on the MySQL deployment. Otherwise, the backend will not be able to establish a connection to the database.

This value tells the backend where to find the database and must match the name of the MySQL service created previously.

As with the database deployment, the secret provides the authentication credentials for the database.

One of the major benefits of using containerized applications is the ability they give you to individually scale specific components. In the backend deployment shown here, the replicas field can be modified to scale the backend. The example Operators in the following chapters use a custom resource to expose this replica count as a first-class configuration value of the Visitors Site custom resource. Users do not need to manually navigate to the specific backend deployment as they do when using manifests. The Operator knows how to appropriately use the entered value.

The service manifest looks similar to the one you created for the database:

apiVersion: v1
kind: Service
metadata:
  name: visitors-backend-service
  labels:
    app: visitors
    tier: backend
spec:
  type: NodePort
  ports:
    - port: 8000  
      targetPort: 8000
      nodePort: 30685  
      protocol: TCP
  selector:
    app: visitors
    tier: backend

As with the database service, the port referenced in the service definition must match up with that exposed by the deployment.

In this example, the backend is configured to run through port 30685 on the same IP as Minikube. The frontend uses this port when making backend calls for data. For simplicity, the frontend defaults to using this value, so it does not need to be specified when the frontend is deployed.

Frontend

The frontend is in a similar position as the backend in the sense that it needs configuration that is consistent with the backend deployment. Once again, it falls on the user to manually verify that these values are consistent in both locations. Here’s the manifest that creates the frontend deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: visitors-frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: visitors
      tier: frontend
  template:
    metadata:
      labels:
        app: visitors
        tier: frontend
    spec:
      containers:
        - name: visitors-frontend
          image: "jdob/visitors-webui:1.0.0"
          imagePullPolicy: Always
          ports:
            - name: visitors
              containerPort: 3000
          env:
            - name: REACT_APP_TITLE  
              value: "Visitors Dashboard"

To make the Visitors Site application more interesting, you can override the home page title through an environment variable. The CR you’ll learn how to create in the next chapters will expose it as a value of the Visitors Site, shielding end users from having to know in which deployment to specify the value.

Similar to the MySQL and backend deployments, the following manifest creates a service that provides access to the frontend deployment:

apiVersion: v1
kind: Service
metadata:
  name: visitors-frontend-service
  labels:
    app: visitors
    tier: frontend
spec:
  type: NodePort
  ports:
    - port: 3000
      targetPort: 3000
      nodePort: 30686  
      protocol: TCP
  selector:
    app: visitors
    tier: frontend

The frontend service looks very similar to the backend service, with the notable difference that it runs on port 30686.