MicroShift is Technology Preview software only.
For more information about the support scope of Red Hat Technology Preview software, see Technology Preview Support Scope.이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Running applications
Running applications in MicroShift
Abstract
Chapter 1. Application deployment with Red Hat build of MicroShift 링크 복사링크가 클립보드에 복사되었습니다!
You can use the kustomize configuration management tool to deploy applications. Read through the following procedure for an example of how this tool works in Red Hat build of MicroShift.
1.1. How manifests work with kustomize 링크 복사링크가 클립보드에 복사되었습니다!
The kustomize configuration management tool is integrated with Red Hat build of MicroShift. At every start, Red Hat build of MicroShift searches the /etc/microshift/manifests and /usr/lib/microshift/ manifest directories for a kustomization.yaml file. If it finds one, Red Hat build of MicroShift automatically runs the equivalent of the kubectl apply -k command to apply the identified manifests to the cluster.
| Location | Intent |
|---|---|
|
| Read-write location for configuration management systems or development. |
|
| Read-only location for embedding configuration manifests on OSTree-based systems. |
1.2. Using manifests example 링크 복사링크가 클립보드에 복사되었습니다!
This example demonstrates automatic deployment of a BusyBox container using kustomize manifests in the /etc/microshift/manifests directory.
Procedure
Create the BusyBox manifest files by running the following commands:
Define the directory location:
MANIFEST_DIR=/etc/microshift/manifests
$ MANIFEST_DIR=/etc/microshift/manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make the directory:
sudo mkdir -p ${MANIFEST_DIR}$ sudo mkdir -p ${MANIFEST_DIR}Copy to Clipboard Copied! Toggle word wrap Toggle overflow Place the YAML file in the directory:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Next, create the
kustomizemanifest files by running the following commands:Place the YAML file in the directory:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Restart Red Hat build of MicroShift to apply the manifests by running the following command:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the manifests and start the
busyboxpod by running the following command:oc get pods -n busybox
$ oc get pods -n busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 2. How Operators work with Red Hat build of MicroShift 링크 복사링크가 클립보드에 복사되었습니다!
You can use Operators with Red Hat build of MicroShift to create applications that monitor the running services in your cluster. Operators can manage applications and their resources, such as deploying a database or message bus. As customized software running inside your cluster, Operators can be used to implement and automate common operations.
Operators offer a more localized configuration experience and integrate with Kubernetes APIs and CLI tools such as kubectl and oc. Operators are designed specifically for your applications. Operators enable you to configure components instead of modifying a global configuration file.
Red Hat build of MicroShift applications are generally expected to be deployed in static environments. However, Operators are available if helpful in your use case. To determine an Operator’s compatibility with Red Hat build of MicroShift, check the Operator’s documentation.
2.1. How to install Operators in Red Hat build of MicroShift 링크 복사링크가 클립보드에 복사되었습니다!
To minimize the footprint of Red Hat build of MicroShift, Operators are installed directly with manifests instead of using the Operator Lifecycle Manager (OLM). The following examples provide instructions on how you can use the kustomize configuration management tool with Red Hat build of MicroShift to deploy an application. Use the same steps to install Operators with manifests.
2.1.1. How manifests work with kustomize 링크 복사링크가 클립보드에 복사되었습니다!
The kustomize configuration management tool is integrated with Red Hat build of MicroShift. At every start, Red Hat build of MicroShift searches the /etc/microshift/manifests and /usr/lib/microshift/ manifest directories for a kustomization.yaml file. If it finds one, Red Hat build of MicroShift automatically runs the equivalent of the kubectl apply -k command to apply the identified manifests to the cluster.
| Location | Intent |
|---|---|
|
| Read-write location for configuration management systems or development. |
|
| Read-only location for embedding configuration manifests on OSTree-based systems. |
2.1.2. Using manifests example 링크 복사링크가 클립보드에 복사되었습니다!
This example demonstrates automatic deployment of a BusyBox container using kustomize manifests in the /etc/microshift/manifests directory.
Procedure
Create the BusyBox manifest files by running the following commands:
Define the directory location:
MANIFEST_DIR=/etc/microshift/manifests
$ MANIFEST_DIR=/etc/microshift/manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make the directory:
sudo mkdir -p ${MANIFEST_DIR}$ sudo mkdir -p ${MANIFEST_DIR}Copy to Clipboard Copied! Toggle word wrap Toggle overflow Place the YAML file in the directory:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Next, create the
kustomizemanifest files by running the following commands:Place the YAML file in the directory:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Restart Red Hat build of MicroShift to apply the manifests by running the following command:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the manifests and start the
busyboxpod by running the following command:oc get pods -n busybox
$ oc get pods -n busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 3. Greenboot workload health check scripts 링크 복사링크가 클립보드에 복사되었습니다!
Greenboot health check scripts are helpful on edge devices where direct serviceability is either limited or non-existent. If you installed the microshift-greenboot RPM package, you can also create health check scripts assess the health of your workloads and applications. These additional health check scripts are useful components of software problem checks and automatic system rollbacks.
A Red Hat build of MicroShift health check script is included in the microshift-greenboot RPM. You can also create your own health check scripts based on the workloads you are running. For example, you can write one that verifies that a service has started.
3.1. How workload health check scripts work 링크 복사링크가 클립보드에 복사되었습니다!
The workload or application health check script described in this tutorial uses the Red Hat build of MicroShift health check functions that are available in the /usr/share/microshift/functions/greenboot.sh file. This enables you to reuse procedures already implemented for the Red Hat build of MicroShift core services.
The script starts by running checks that the basic functions of the workload are operating as expected. To run the script successfully:
- Execute the script from a root user account.
- Enable the Red Hat build of MicroShift service.
The health check performs the following actions:
-
Gets a wait timeout of the current boot cycle for the
wait_forfunction. -
Calls the
namespace_images_downloadedfunction to wait until pod images are available. -
Calls the
namespace_pods_readyfunction to wait until pods are ready. -
Calls the
namespace_pods_not_restartingfunction to verify pods are not restarting.
Restarting pods can indicate a crash loop.
3.2. Included greenboot health checks 링크 복사링크가 클립보드에 복사되었습니다!
Health check scripts are available in /usr/lib/greenboot/check, a read-only directory in RPM-OSTree systems. The following health checks are included with the greenboot-default-health-checks framework.
Check if repository URLs are still DNS solvable:
This script is under
/usr/lib/greenboot/check/required.d/01_repository_dns_check.shand ensures that DNS queries to repository URLs are still available.Check if update platforms are still reachable:
This script is under
/usr/lib/greenboot/check/wanted.d/01_update_platform_check.shand tries to connect and get a 2XX or 3XX HTTP code from the update platforms defined in/etc/ostree/remotes.d.Check if the current boot has been triggered by the hardware watchdog:
This script is under
/usr/lib/greenboot/check/required.d/02_watchdog.shand checks whether the current boot has been watchdog-triggered or not.- If the watchdog-triggered reboot occurs within the grace period, the current boot is marked as red. Greenboot does not trigger a rollback to the previous deployment.
- If the watchdog-triggered reboot occurs after the grace period, the current boot is not marked as red. Greenboot does not trigger a rollback to the previous deployment.
-
A 24-hour grace period is enabled by default. This grace period can be either disabled by modifying
GREENBOOT_WATCHDOG_CHECK_ENABLEDin/etc/greenboot/greenboot.conf to false, or configured by changing theGREENBOOT_WATCHDOG_GRACE_PERIOD=number_of_hoursvariable value in/etc/greenboot/greenboot.conf.
3.3. How to create a health check script for your application 링크 복사링크가 클립보드에 복사되었습니다!
You can create workload or application health check scripts in the text editor of your choice using the example in this documentation. Save the scripts in the /etc/greenboot/check/required.d directory. When a script in the /etc/greenboot/check/required.d directory exits with an error, greenboot triggers a reboot in an attempt to heal the system.
Any script in the /etc/greenboot/check/required.d directory triggers a reboot if it exits with an error.
If your health check logic requires any post-check steps, you can also create additional scripts and save them in the relevant greenboot directories. For example:
-
You can also place shell scripts you want to run after a boot has been declared successful in
/etc/greenboot/green.d. -
You can place shell scripts you want to run after a boot has been declared failed in
/etc/greenboot/red.d. For example, if you have steps to heal the system before restarting, you can create scripts for your use case and place them in the/etc/greenboot/red.ddirectory.
3.3.1. About the workload health check script example 링크 복사링크가 클립보드에 복사되었습니다!
The following example uses the Red Hat build of MicroShift health check script as a template. You can use this example with the provided libraries as a guide for creating basic health check scripts for your applications.
3.3.1.1. Basic prerequisites for creating a health check script 링크 복사링크가 클립보드에 복사되었습니다!
- The workload must be installed.
- You must have root access.
3.3.1.2. Example and functional requirements 링크 복사링크가 클립보드에 복사되었습니다!
You can start with the following example health check script. Modify it for your use case. In your workload health check script, you must complete the following minimum steps:
- Set the environment variables.
- Define the user workload namespaces.
- List the expected pod count.
Choose a name prefix for your application that ensures it runs after the 40_microshift_running_check.sh script, which implements the Red Hat build of MicroShift health check procedure for its core services.
Example workload health check script
3.4. Testing a workload health check script 링크 복사링크가 클립보드에 복사되었습니다!
Prerequisites
- You have root access.
- You have installed a workload.
- You have created a health check script for the workload.
- The Red Hat build of MicroShift service is enabled.
Procedure
To test that greenboot is running a health check script file, reboot the host by running the following command:
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow Examine the output of greenboot health checks by running the following command:
sudo journalctl -o cat -u greenboot-healthcheck.service
$ sudo journalctl -o cat -u greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRed Hat build of MicroShift core service health checks run before the workload health checks.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow