Untitled Publication

connect Amavis to an external ClamAV daemon using TCP

Syarif — Sun, 30 Aug 2026 19:33:13 GMT

To connect Amavis to an external ClamAV daemon using TCP, update your Amavis configuration (typically in /etc/amavis/conf.d/50-user or /etc/amavisd/amavisd.conf).

1. Update `@av_scanners` Configuration

Replace or update your @av_scanners array with the following syntax:
@av_scanners = ( ['ClamAV-clamd', &ask_daemon, ["{}/", "clamd:CLAMAV_HOST:3310"], qr/\bOK$/m, qr/\bFOUND$/m, qr/^.?: (?!Infected Archive)(.*) FOUND$/m ], );

Replace CLAMAV_HOST with your ClamAV container/server hostname or IP address.

Crucial Syntax Rules clamd: scheme prefix: Required so ask_daemon matches the protocol to clamav_clamd_internal. Using tcp: or clamav: will cause Unsupported AV protocol name errors.

"{}/*" placeholder: Passes individual extracted MIME files. Using "{}" passes the directory path, causing Is a directory errors during TCP streaming (zINSTREAM).

Single string endpoint: Formatted as "clamd:HOST:PORT". Passing an array reference like ["HOST", 3310] causes Amavis to misinterpret the host as a local UNIX socket.

Restart and Test Restart the Amavis service or container to reload the configuration:

Bash systemctl restart amavis Inject the EICAR test string to verify the scan:

Bash printf "X5O!P%%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*" | sendmail postmaster@yourdomain.com Check your mail log for a successful block:

Plaintext amavis[...]: (...) Blocked INFECTED (Eicar-Signature) ...

Running the Traefik 3 Hardened Image (nonroot) on Podman: 3 Problems and Their Fixes

Syarif — Thu, 06 Aug 2026 03:01:01 GMT

Docker Hardened Images (DHI) give you production-ready images with a small attack surface: no shell, no package manager, and — this is the part that confuses people the most — they run as a nonroot user (UID 65532) by default. This is great for security. But if you switch your old image to dhi.io/traefik:3-alpine without any changes, you will almost certainly hit a few errors.

This article covers three problems I found while moving a Traefik reverse proxy to DHI on top of Podman (rootful), along with the root cause and the fix for each one.

The starting setup

A simple stack: Traefik as a reverse proxy plus a Cloudflare Tunnel, running on Podman with the socket mounted in place of the Docker socket:

services:
  traefik:
    image: dhi.io/traefik:3-alpine
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.http.address=:8080"
      - "--entrypoints.https.address=:8443"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http"
      - "--certificatesresolvers.letsencrypt.acme.email=your-email@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:8080"
      - "443:8443"
    volumes:
      - traefik_letsencrypt:/letsencrypt
      - "/run/podman/podman.sock:/var/run/docker.sock:ro,z"

  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=${CLOUDFLARE_TUNNEL_TOKEN}

volumes:
  traefik_letsencrypt:

This looks normal. But once you run docker compose up, three problems appear one after another.

Problem 1: `listen tcp :8080: bind: address already in use`

The first instinct is usually: "a nonroot user can't bind to a privileged port." But look closely at the error message — it says address already in use, not permission denied. These are two different errors with two different causes.

Root cause: --api.insecure=true without an explicit entrypoint makes Traefik automatically create an internal entrypoint called traefik for the dashboard. This entrypoint also defaults to :8080. If your config already sets another entrypoint to :8080 too, both listeners try to bind the same port inside the same process.

Fix: give the dashboard its own port, separate from the web entrypoint:

command:
  - "--api.dashboard=true"
  - "--api.insecure=true"
  - "--entrypoints.http.address=:8080"
  - "--entrypoints.https.address=:8443"
  - "--entrypoints.traefik.address=:8081"   # dashboard, its own port

A quick note on privileged ports: on Docker Engine 20.10 and later, a nonroot user can actually still bind to ports below 1024. But on Kubernetes or older engines, you still need to use ports above 1024 inside the container (as shown above), then map them to 80/443 with ports:.

Problem 2: `permission denied` when connecting to the Podman socket

Once the port issue is fixed, the next error shows up:

Failed to retrieve information of the docker client and server host
error="permission denied while trying to connect to the docker API
at unix:///var/run/docker.sock" providerName=docker

Root cause: UID 65532 (nonroot) doesn't match the owner or group of podman.sock on the host, which is usually:

root root 660

Since the DHI image has no shell, you can't run chmod or chown from inside the container. A few quick fixes exist — using an ACL, or changing the socket's group to GID 65532 — but they both have two downsides:

Host permissions can reset every time the socket service restarts (you'd need a systemd override to make it permanent).
More importantly: giving direct socket access means giving Traefik full root-level access to the entire container engine on the host. If Traefik (which faces the public internet) gets compromised, the attacker gets full control over every container.

Problem 3: The real fix — a Docker/Podman Socket Proxy

The correct solution for this combination — nonroot, hardened image, and a publicly-facing reverse proxy — is to not give Traefik socket access at all. Instead, put a dedicated proxy between Traefik and the socket, one that only allows the read-only endpoints actually needed for service discovery.

services:
  socket-proxy:
    image: lscr.io/linuxserver/socket-proxy:latest
    restart: unless-stopped
    environment:
      - CONTAINERS=1   # list containers (required for discovery)
      - NETWORKS=1     # resolve container networks (required for routing)
      - EVENTS=1       # live updates when containers start/stop
      # everything else stays at the default 0 (deny)
    volumes:
      - "/run/podman/podman.sock:/var/run/docker.sock:ro,z"
    networks:
      - socket-proxy-net

  traefik:
    image: dhi.io/traefik:3-alpine
    command:
      - "--api.dashboard=true"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.endpoint=tcp://socket-proxy:2375"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.http.address=:8080"
      - "--entrypoints.https.address=:8443"
      - "--entrypoints.traefik.address=:8081"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http"
      - "--certificatesresolvers.letsencrypt.acme.email=your-email@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:8080"
      - "443:8443"
    volumes:
      - traefik_letsencrypt:/letsencrypt
    networks:
      - socket-proxy-net
      - default
    depends_on:
      - socket-proxy

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=${CLOUDFLARE_TUNNEL_TOKEN}
    networks:
      - default

networks:
  socket-proxy-net:
    internal: true
  default:

volumes:
  traefik_letsencrypt:

The socket-proxy-net network is marked internal: true so it stays fully isolated. Nothing outside this network can reach it, even if the socket-proxy port is accidentally exposed somewhere else.

Why this approach is better

Aspect	Direct socket mount	Socket proxy
Requires host permission changes	Yes (chmod/setfacl, breaks on restart)	No
Works with a nonroot image that has no shell	Needs a workaround	Works natively, no issues
API access if the container is compromised	Full read-write access to the whole engine	Read-only, limited to containers/networks/events
Label-based autodiscovery	Works	Still works, no changes needed

That last point matters most: Traefik's label-based autodiscovery (traefik.enable=true, and so on) doesn't change at all. Traefik still uses the same providers.docker setup — only the endpoint now points to the proxy instead of the raw socket.

Summary

If you're moving Traefik to a hardened or nonroot image (or any production image that runs as nonroot) on top of Docker or Podman:

Don't assume a port error is always about privileges. Check the error message closely — already in use is not the same as permission denied, and each one has a different cause and a different fix.
Give the dashboard/API its own entrypoint, separate from the web entrypoint, when using api.insecure=true. This avoids implicit port conflicts.
Never mount the container engine socket directly into a publicly-facing reverse proxy. Use a socket proxy with the narrowest read-only permissions possible. This isn't just a workaround for the nonroot permission issue — it's good security practice regardless of which user your container runs as.

Note: the examples above use rootful Podman with the socket at /run/podman/podman.sock. If you're using regular Docker, change the socket path to /var/run/docker.sock.

Why I Didn’t Trust Bitcoin at First — Until I Found a Way to Solve Its Biggest Problem

Syarif — Thu, 19 Jun 2025 08:25:08 GMT

Like many others, I wasn’t exactly against Bitcoin — but I had serious concerns. It wasn’t price volatility or market speculation that made me hesitant. My main worry was: what if I lose access to my wallet?

The Fear of Permanent Loss

Imagine this:

I forget my password
I misplace my recovery phrase
Someone steals it
I suffer from memory loss
Or worse — I pass away

In any of these cases, my Bitcoin could be gone forever.

Years ago, when Bitcoin was still new, I couldn’t find a reliable way to deal with this. I remember reading about a man digging through a landfill for years, trying to recover a hard drive with lost Bitcoin worth millions. That could be anyone.

Then there’s the question of exchanges. Buying Bitcoin through an exchange might feel convenient, but what if the exchange goes bankrupt? Unlike traditional banks — which at least offer some legal means of recovery — there’s no such fallback with most crypto exchanges. If they disappear, so might your assets.

Unfortunately, many people I asked back then simply said, "just accept the risk."
That wasn’t good enough for me.

How I Found a Better Way

Fast forward to today — the world has changed, and so has crypto. But surprisingly, many people still don’t know how to prepare for worst-case scenarios like death or memory loss. That’s why I want to share the system I use today, which could also help others.

Everyday Usage: Multi-Signature Wallet

In a typical family structure — husband, wife, and two children — I use a 2-of-3 multisig wallet. This means that any transaction must be approved by at least two people. This prevents a single point of failure and helps protect against misuse or accidents.
Long-Term Inheritance: Shamir Backup

For legacy and inheritance, I use a Shamir Secret Sharing method with a 6-of-9 setup. The wallet’s seed phrase is divided into 9 pieces. Any 6 of them can be combined to recover the wallet. The distribution looks like this:
- Husband: 2 shares (kept in a bank safe deposit box)
- Wife: 2 shares (also in a separate safe deposit box)
- Child 1: 1 share
- Child 2: 1 share
- Husband Trusted Person: 1 share
- Wife trusted person: 1 share
- netral person / Lawyer: 1 share

This creates a balance of security, trust, and accessibility — even in the event of my death. With joining six share, my family can still recover the funds responsibly.

"Not Your Keys, Not Your Coins"

I still don’t fully trust exchanges.
Crypto's golden rule remains:

If you don’t own the keys, you don’t own the assets.

Most exchanges keep your funds in wallets they control. Several years ago, an incident involving Indodax, one of Indonesia’s popular exchanges, reaffirmed my stance — exchanges are not safe places to store crypto long-term.

Sure, exchanges are necessary for buying and selling. But for storage, I always withdraw to my personal wallet.

Choosing an Exchange Wisely

Exchanges differ wildly in fees — transaction fees, withdrawal fees, and even taxation policies. Some are rigid, some are fair. After trying several platforms, I found the most competitive (at least as of writing this article) to be:
https://reku.id/

Final Thoughts

Owning Bitcoin is about freedom, but with freedom comes responsibility. It’s not just about investment or speculation — it’s about building a system that protects your assets, even when you’re no longer here.

I hope my approach can inspire others to take ownership of their crypto securely, responsibly, and wisely.

In this article, I discuss my initial concerns about the security and accessibility of Bitcoin and how my approach has evolved over time. To mitigate risks like loss of access or inheritance issues, I use a 2-of-3 multi-signature wallet for everyday transactions and Shamir Secret Sharing for long-term inheritance planning. I emphasize the importance of owning your private keys to ensure control over your assets and recommend cautious use of exchanges for storage. The article aims to offer a practical framework for managing Bitcoin securely and responsibly.

How to Create a Free Email Account with a Custom Domain Name in Zoho.com

Syarif — Wed, 12 Jul 2023 11:37:33 GMT

Introduction: Having a professional email address that matches your domain name adds credibility and authenticity to your online presence. Zoho.com offers a free plan that allows you to create email accounts with your custom domain name. In this article, we will guide you through the process of setting up a free email account using Zoho.com, enabling you to communicate professionally and effectively with your custom domain.

Step 1: Sign up for a Zoho.com Account Visit the Zoho.com website at https://www.zoho.com and sign up for a free account. Provide the required information, including your name, email address, and a secure password. Once registered, log in to your Zoho.com account.

Step 2: Verify Your Domain After logging in, Zoho.com will guide you through the process of verifying your domain ownership. Choose the "Verify Domain" option and follow the instructions provided. This typically involves adding a DNS TXT record or creating a CNAME record with your domain registrar.

Step 3: Add Email Accounts Once your domain is verified, you can add email accounts with your custom domain. In the Zoho.com dashboard, navigate to the "Mail" section and select "User Details." Click the "+ New User" button and enter the required details, such as the username and password for your email account.

Step 4: Configure Email Delivery To receive emails in your Zoho.com email account, you need to configure the email delivery settings. In the Zoho.com dashboard, go to the "Mail" section and select "Email Delivery" or "Control Panel." Follow the provided instructions to set up the necessary MX records with your domain registrar.

Step 5: Access Your Email Account Once the MX records are set up and propagated, you can access your email account using your custom domain. Visit the Zoho.com website, log in to your account, and navigate to the "Mail" section. Here, you can access your inbox, compose and send emails, set up email signatures, and manage other email-related settings.

Step 6: Configure Email Clients and Devices To access your Zoho.com email account through email clients or mobile devices, you need to configure the appropriate settings. Zoho.com provides detailed instructions for popular email clients like Outlook, Thunderbird, and mobile devices like Android and iOS. Follow the step-by-step instructions provided by Zoho.com to set up your email account on your preferred client or device.

Step 7: Customize Email Settings Zoho.com offers various customization options to tailor your email experience. Explore the settings in your Zoho.com account to personalize your email account's appearance, email filters, autoresponders, and other preferences.

Step 8: Manage Additional Features (Optional) Zoho.com offers additional features and services, such as calendar integration, document collaboration, and task management. Explore the Zoho.com dashboard to discover and utilize these features to enhance your productivity and communication.

Step 9: Maintain Security and Backups To ensure the security of your email account and data, enable two-factor authentication (2FA) in your Zoho.com account settings. Additionally, consider regularly backing up your emails to prevent any accidental data loss.

Step 10: Regularly Manage and Monitor Regularly manage your email account settings, check your inbox, and monitor any security notifications or updates from Zoho.com. Staying vigilant and proactive will help you maintain a secure and efficient email communication system.

Conclusion: With Zoho.com, you can create a free email account with a custom domain name, enabling you to communicate professionally and effectively. By following the steps outlined in this article, you can set up your email account, configure email delivery, access your inbox, and customize settings according to your preferences. Take advantage of Zoho.com's features and services to streamline your email communication and enhance your online presence.

How to Manage Your Domain for Free Using Cloudflare

Syarif — Wed, 12 Jul 2023 11:35:54 GMT

Introduction: Cloudflare is a powerful platform that offers various services to enhance your website's performance, security, and reliability. In addition to these features, Cloudflare also provides a free plan that allows you to manage your domain effectively. This article will guide you through the process of managing your domain using Cloudflare's free plan. By following these steps, you can take advantage of Cloudflare's robust management tools without any cost.

Step 1: Sign up for a Cloudflare Account Visit the Cloudflare website at https://www.cloudflare.com and sign up for a free account. Provide the required information, including your email address and a secure password. Once registered, log in to your Cloudflare account.

Step 2: Add Your Domain to Cloudflare After logging in, you will be prompted to add your domain to Cloudflare. Enter your domain name in the provided field and click the "Add Site" button. Cloudflare will scan your domain's DNS records to identify the existing settings.

Step 3: Verify DNS Records Cloudflare will display a list of DNS records it discovered for your domain. Ensure that all necessary records are listed correctly. Review the records related to your website's main domain (e.g., A, CNAME) and any subdomains you want to manage.

Step 4: Update Name Servers To activate Cloudflare's management for your domain, you need to update your domain's name servers. Cloudflare will provide you with two nameserver addresses. Take note of these addresses and proceed to update the nameservers with your domain registrar.

Step 5: Confirm DNS Propagation After updating the nameservers, it may take some time for the changes to propagate across the internet. You can use online tools like "DNS Propagation Checker" to verify if the nameserver update is complete. Once the propagation is confirmed, Cloudflare will begin managing your domain.

Step 6: Configure DNS Settings Once your domain is active on Cloudflare, you can access various DNS management settings. Navigate to the "DNS" section in your Cloudflare account. Here, you can add, modify, or delete DNS records for your domain and subdomains. Make any necessary changes to align with your website's requirements.

Step 7: Enable SSL/TLS Encryption Cloudflare provides free SSL/TLS certificates for your domain, ensuring secure communication between your website and visitors. In the "SSL/TLS" section of your Cloudflare account, enable the "Flexible," "Full," or "Full (Strict)" SSL mode, depending on your website configuration. This step helps secure your domain with HTTPS.

Step 8: Utilize Cloudflare Features Cloudflare offers various features to enhance your website's performance, security, and caching. Explore the "Speed," "Caching," "Firewall," and other sections in your Cloudflare account to take advantage of these capabilities. Enable or customize features based on your website's specific needs.

Step 9: Monitor and Analyze Cloudflare provides comprehensive analytics and insights about your website's performance, visitors, and threats. Explore the "Analytics" section to gain valuable information and make data-driven decisions to optimize your website's performance and security.

Step 10: Periodically Review and Update Regularly review and update your Cloudflare settings as your website evolves. Ensure that DNS records, security configurations, and performance optimizations remain up to date. Cloudflare's user-friendly interface makes it easy to manage your domain effectively.

Conclusion: By utilizing Cloudflare's free plan, you can effectively manage your domain without any additional cost. From DNS management to SSL/TLS encryption and advanced features, Cloudflare offers a comprehensive suite of tools to enhance your website's performance and security. Follow the steps outlined in this article to set up and manage your domain using Cloudflare, and enjoy the benefits of this powerful platform without breaking your budget.

How to Buy a Domain Name from IDCloudHost.com

Syarif — Wed, 12 Jul 2023 11:34:13 GMT

Introduction: Choosing the right domain name is a crucial step when establishing your online presence. IDCloudHost.com is a reputable domain registrar that offers a wide range of domain name options. In this article, we will guide you through the process of buying a domain name from IDCloudHost.com. Whether you're a business owner, blogger, or individual looking to create a website, this step-by-step tutorial will help you navigate the domain purchase process.

Step 1: Visit IDCloudHost.com Open your preferred web browser and go to the official website of IDCloudHost.com at https://www.idcloudhost.com.

Step 2: Search for Your Desired Domain Name On the IDCloudHost.com homepage, you will find a domain search box. Enter the domain name you want to purchase and click the "Search" button. IDCloudHost.com will display the availability and pricing of the domain name you entered.

Step 3: Choose Your Domain Extension IDCloudHost.com offers a variety of domain extensions, such as .com, .net, .org, and many more. Select the extension that best suits your website's purpose and audience. Consider factors like branding, target market, and industry relevance when making your choice.

Step 4: Add the Domain to Your Cart Once you've decided on the domain name and extension, click the "Add to Cart" or "Buy Now" button to add it to your shopping cart.

Step 5: Review Your Cart After adding the domain to your cart, you will be redirected to a page where you can review your order details. Ensure that the domain name, extension, and pricing are correct before proceeding.

Step 6: Choose Additional Services (Optional) IDCloudHost.com offers various additional services, such as WHOIS privacy protection, SSL certificates, and website hosting. You can select any desired add-ons during the checkout process. Consider your specific needs and budget when deciding on these services.

Step 7: Proceed to Checkout Click the "Checkout" or "Proceed to Checkout" button to proceed with your domain purchase. You may need to create an account if you don't already have one. Fill in the required information, including your name, email address, billing address, and payment details.

Step 8: Complete the Payment Choose your preferred payment method and provide the necessary information to complete the transaction securely. IDCloudHost.com accepts various payment options, including credit/debit cards, bank transfers, and e-wallets.

Step 9: Verify and Confirm Your Purchase Carefully review your order summary, including the domain name, pricing, and additional services. Once you are satisfied, click the "Confirm Purchase" or "Place Order" button to finalize your domain name purchase.

Step 10: Manage Your Domain After completing your purchase, IDCloudHost.com will provide you with instructions on managing your domain. You can configure DNS settings, set up email accounts, and link the domain to your website hosting.

Conclusion: Buying a domain name from IDCloudHost.com is a straightforward process. By following the steps outlined in this article, you can successfully register a domain name that aligns with your online goals. Remember to choose a domain name that reflects your brand, is memorable, and resonates with your target audience. Establishing a strong online presence starts with securing the right domain name, and IDCloudHost.com offers a convenient platform to make that happen.

Lab: Troubleshoot and Scale Applications

Syarif — Wed, 12 Jul 2023 11:26:42 GMT

Navigate the OpenShift web console to identify CPU-consuming workloads.

Troubleshoot and fix a failed MySQL pod.

Manually scale an application.

Configure health probes.

Outcomes

You should be able to troubleshoot malfunctioning workloads, configure deployments, and scale applications.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. The command also creates the compreview-scale project and deploys some applications in that project.

The command creates the /home/student/DO180/labs/compreview-scale/resources.txt file. The resources.txt file contains the URLs of your OpenShift cluster and the name of the images that you use during the exercise. You can use the file to copy and paste these URLs and image names.

[student@workstation ~]$ lab start compreview-scale

Specifications

The API URL of your OpenShift cluster is https://api.ocp4.example.com:6443, and the oc command is already installed on your workstation machine.

The URL of the OpenShift web console is https://console-openshift-console.apps.ocp4.example.com. When you access the web console, select Red Hat Identity Management as the authentication mechanism.

Log in to the OpenShift cluster as the developer user with the developer password. The password for the admin user is redhatocp.

Perform the following tasks to complete the comprehensive review:

A pod in the cluster is consuming excessive CPU and is interfering with other tasks. Identify the pod and remove its workload.
The compreview-scale project already includes a web application at http://frontend-compreview-scale.apps.ocp4.example.com. When you access this URL, the application returns a list of quotations from famous authors. The application is broken for now, and is missing some configuration to be ready for production.

The application uses two Kubernetes Deployment objects. The frontend deployment provides the application web pages, and relies on the quotesdb deployment that runs a MySQL database. The lab command already created the services and routes that connect the application components and that make the application available from outside the cluster.

Fix the application and make it ready for production:
- The quotesdb deployment in the compreview-scale project starts a MySQL server, but the database is failing. Review the logs of the pod to identify and then fix the issue.
  
  Use the following parameters for the database:
  
  | Name | Value | | --- | --- | | Username | operator1 | | Password | redhat123 | | Database name | quotes |
- You security team validated a new version of the MySQL container image that fixes a security issue. The new container image is registry.ocp4.example.com:8443/rhel9/mysql-80:1-237.
  
  Update the quotesdb deployment to use this image. Ensure that the database redeploys.
  
  The classroom setup copied the image from the Red Hat Ecosystem Catalog. The original image is registry.redhat.io/rhel9/mysql-80:1-237.
- Add a probe to the quotesdb deployment so that OpenShift can detect when the database is ready to accept requests. Use the mysqladmin ping command for the probe.
- Add a second probe that regularly verifies the status of the database. Use the mysqladmin ping command as well.
- Configure CPU and memory usage for the quotesdb deployment. The deployment needs 200 millicores of CPU and 256 MiB of memory to run, and you must restrict its CPU usage to 500 millicores and its memory usage to 1 GiB.
- Add a probe to the frontend deployment so that OpenShift can detect when the web application is ready to accept requests. The application is ready when an HTTP request on port 8000 to the /status path is successful.
- Add a second probe that regularly verifies the status of the web front end. The front end works as expected when an HTTP request on port 8000 to the /env path is successful.
- Configure CPU and memory usage for the frontend deployment. The deployment needs 200 millicores of CPU and 256 MiB of memory to run, and you must restrict its CPU usage to 500 millicores and its memory usage to 512 MiB.
- Scale the frontend application to three pods to accommodate for the estimated production load.
- To verify your work, access the http://frontend-compreview-scale.apps.ocp4.example.com URL. The application returns a list of quotations from famous authors.

Use the OpenShift web console to identify and then delete the pod that consumes excessive CPU.
1. Use a web browser to access the https://console-openshift-console.apps.ocp4.example.com URL.
2. Select Red Hat Identity Management, and then log in as the admin user with the redhatocp password. Click Skip tour if the Welcome to the Developer Perspective message is displayed.
3. Switch to the Administrator perspective and then navigate to Observe → Dashboards.
4. Select the Kubernetes / Compute Resources / Cluster dashboard, and then click Inspect in the CPU Usage graph.
5. Set the zoom to five minutes and then hover over the graph. Notice that the interface lists the compreview-scale-load namespace in the first position, which indicated that this namespace is the first CPU consumer.
6. Navigate to Observe → Dashboards and then select the Kubernetes / Compute Resources / Namespace (Workloads) dashboard. Select the compreview-scale-load namespace and then set the time range to the last five minutes. The computeprime deployment is the workload that consumes excessive CPU.
7. Navigate to Workloads → Deployments and then select the compreview-scale-load project. Select the menu for the computeprime deployment and then click Delete Deployment. Click Delete to confirm the operation.

Review the logs of the pod that is failing for the quotesdb deployment. Set the missing environment variables in the quotesdb deployment.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the compreview-scale project as the active project.

 [student@workstation ~]$ oc project compreview-scale
 ...output omitted...

List the pods to identify the failing pod from the quotesdb deployment. The names of the pods on your system probably differ.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS             RESTARTS         AGE
 frontend-5fb85b4c75-5s7xr   0/1     CrashLoopBackOff   14 (2m52s ago)   50m
 quotesdb-9b9776479-4z4g9    0/1     CrashLoopBackOff   14 (3m4s ago)    50m

Retrieve the logs for the failing pod. Some environment variables are missing.

 [student@workstation ~]$ oc logs quotesdb-9b9776479-4z4g9
 => sourcing 20-validate-variables.sh ...
 You must either specify the following environment variables:
   MYSQL_USER (regex: '^[a-zA-Z0-9_]+$')
   MYSQL_PASSWORD (regex: '[a-zA-Z0-9_~!@#$%&*()-=<>,.?;:|]+$')
   MYSQL_DATABASE (regex: '^[a-zA-Z0-9_]+$')
 ...output omitted...

Add the missing environment variables to the quotesdb deployment. Ignore the warning message.

 [student@workstation ~]$ oc set env deployment/quotesdb \
   MYSQL_USER=operator1  MYSQL_PASSWORD=redhat123 MYSQL_DATABASE=quotes
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb updated

Update the MySQL container image for the quotesdb deployment.

Retrieve the name of the container that is running inside the pod. You need the container name to update its image.

 [student@workstation ~]$ oc get deployment/quotesdb -o wide
 NAME       READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS ...
 quotesdb   1/1     1            1           59m   mysql-80   ...

Set the image to registry.ocp4.example.com:8443/rhel9/mysql-80:1-237. Ignore the warning message.

 [student@workstation ~]$ oc set image deployment/quotesdb \
   mysql-80=registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb image updated

Verify your work.

 [student@workstation ~]$ oc get deployment/quotesdb -o wide
 NAME      ... CONTAINERS   IMAGES
 quotesdb  ... mysql-80     registry.ocp4.example.com:8443/rhel9/mysql-80:1-237

Wait for the deployment to roll out. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS             RESTARTS         AGE
 frontend-5fb85b4c75-5s7xr   0/1     CrashLoopBackOff   15 (3m39s ago)   56m
 quotesdb-54d64749c4-chhq6   1/1     Running            0                106s

Add a readiness and a liveness probe to the quotesdb deployment that runs the mysqladmin ping command.

Use the oc set probe command with the --readiness option to add the readiness probe. Ignore the warning message.

 [student@workstation ~]$ oc set probe deployment/quotesdb \
   --readiness -- mysqladmin ping
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb probes updated

Use the oc set probe command with the --liveness option to add the liveness probe. Ignore the warning message.

 [student@workstation ~]$ oc set probe deployment/quotesdb \
   --liveness -- mysqladmin ping
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb probes updated

Define resource limits for the quotesdb deployment. Set the CPU request to 200 millicores and the memory request to 256 MiB. Set the CPU limit to 500 millicores and the memory limit to 1 GiB. Ignore the warning message.

 [student@workstation ~]$ oc set resources deployment/quotesdb \
   --requests cpu=200m,memory=256Mi --limits cpu=500m,memory=1Gi
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb resource requirements updated

Add a readiness and a liveness probe to the frontend deployment.

Use the oc set probe command with the --readiness option to add the readiness probe that tests the /status path on HTTP port 8000. Ignore the warning message.

 [student@workstation ~]$ oc set probe deployment/frontend --readiness \
   --get-url http://:8000/status
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/frontend probes updated

Use the oc set probe command with the --liveness option to add the liveness probe that tests the /env path on HTTP port 8000. Ignore the warning message.

 [student@workstation ~]$ oc set probe deployment/frontend --liveness \
   --get-url http://:8000/env
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/frontend probes updated

Define resource limits for the frontend deployment. Set the CPU request to 200 millicores and the memory request to 256 MiB. Set the CPU limit to 500 millicores and the memory limit to 512 MiB. Ignore the warning message.

 [student@workstation ~]$ oc set resources deployment/frontend \
   --requests cpu=200m,memory=256Mi --limits cpu=500m,memory=512Mi
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/frontend resource requirements updated

Scale the frontend deployment to three pods.

Scale the deployment.

 [student@workstation ~]$ oc scale deployment/frontend --replicas 3
 deployment.apps/frontend scaled

Wait for the deployment to scale up. You might have to rerun the command several times for the pods to report a Running status. The names of the pods on your system probably differ.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 frontend-86cdd7c7bf-8vrrs   1/1     Running   0          3m10s
 frontend-86cdd7c7bf-ds79w   1/1     Running   0          44s
 frontend-86cdd7c7bf-hpnwz   1/1     Running   0          44s
 quotesdb-66ff98b88c-fhwhs   1/1     Running   0          12m

Verify that the application responds to web requests.

Retrieve the URL of the application.

 [student@workstation ~]$ oc get route
 NAME       HOST/PORT                                         PATH   SERVICES ...
 frontend   frontend-compreview-scale.apps.ocp4.example.com          frontend ...

Use the curl command to test the application.

 [student@workstation ~]$ curl \
   http://frontend-compreview-scale.apps.ocp4.example.com
 
     
         Quotes
     
     

         Quote List

             

                     1: When words fail, music speaks.
 - William Shakespeare
 
 ...output omitted...

Hide Solution

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade compreview-scale

Finish

As the student user on the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish compreview-scale

Lab: Deploy Web Applications

Syarif — Wed, 12 Jul 2023 11:25:20 GMT

Use image streams with Kubernetes workload resources to ensure reproducibility of application deployments.

Configure applications by using Kubernetes secrets to initialize environment variables.

Provide applications with persistent storage volumes.

Expose applications to clients outside the cluster.

Outcomes

You should be able to create and configure OpenShift and Kubernetes resources, such as projects, secrets, deployments, persistent volumes, services, and routes.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. The command also creates the /home/student/DO180/labs/compreview-deploy/resources.txt file. The resources.txt file contains the URLs of your OpenShift cluster and the image names that you use in the exercise. You can use the file to copy and paste these URLs and image names.

[student@workstation ~]$ lab start compreview-deploy

Specifications

The API URL of your OpenShift cluster is https://api.ocp4.example.com:6443, and the oc command is already installed on your workstation machine.

Log in to the OpenShift cluster as the developer user with the developer password. The password for the admin user is redhatocp, although you do not need administrator privileges to complete the exercise.

In this exercise, you deploy a web application and its database for testing purposes. The resulting configuration is not ready for production, because you do not configure probes and resource limits, which are required for production. Another comprehensive review exercise covers these subjects.

Perform the following tasks to complete the exercise:

Create a project named review to store all of your work.
Configure your project so that its workloads refer to the database image by the mysql8:1 short name.
- The short name must point to the registry.ocp4.example.com:8443/rhel9/mysql-80:1-228 container image. The database image name and its source registry are expected to change in the near future, and you want to isolate your workloads from that change.
  
  The classroom setup copied the image from the Red Hat Ecosystem Catalog. The original image is registry.redhat.io/rhel9/mysql-80:1-228.
- Ensure that the workload resources in the review project can use the mysql8:1 resource. You create these workload resources in a later step.
Create the dbparams secret to store the MySQL database parameters. Both the database and the front-end deployment need these parameters. The dbparams secret must include the following variables:

| Name | Value | | --- | --- | | user | operator1 | | password | redhat123 | | database | quotesdb |
Create the quotesdb deployment and configure it as follows:
- Use the mysql8:1 image for the deployment.
- The database must automatically roll out whenever the source container in the mysql8:1 resource changes.
  
  To test your configuration, you can change the mysql8:1 image to point to the registry.ocp4.example.com:8443/rhel9/mysql-80:1-237 container image that the classroom provides, and then verify that the quotesdb deployment rolls out. Remember to reset the mysql8:1 image to the registry.ocp4.example.com:8443/rhel9/mysql-80:1-228 container image before grading your work.
- Define the following environment variables in the deployment from the keys in the dbparams secret:
  
  | Environment variable | dbparams secret key | | --- | --- | | MYSQL_USER | user | | MYSQL_PASSWORD | password | | MYSQL_DATABASE | database |
- Ensure that OpenShift preserves the database data between pod restarts. This data does not consume more than 2 GiB of disk space. The MySQL database stores its data under the /var/lib/mysql directory. Use the lvms-vg1 storage class for the volume.
Create a quotesdb service to make the database available to the front-end web application. The database service is listening on port 3306.
Create the frontend deployment and configure it as follows:
- Use the registry.ocp4.example.com:8443/redhattraining/famous-quotes:2-42 image. For this deployment, you refer to the image by its full name, because your organization develops the image and controls its release process.
- Define the following environment variables in the deployment:
  
  | Environment variable name | Value | | --- | --- | | QUOTES_USER | The user key from the dbparams secret | | QUOTES_PASSWORD | The password key from the dbparams secret | | QUOTES_DATABASE | The database key from the dbparams secret | | QUOTES_HOSTNAME | quotesdb |
You cannot yet test the application from outside the cluster. Expose the frontend deployment so that the application can be reached at http://frontend-review.apps.ocp4.example.com.

The frontend deployment is listening to port 8000.

When you access the http://frontend-review.apps.ocp4.example.com URL, the application returns a list of quotations from famous authors.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Create the review project.

 [student@workstation ~]$ oc new-project review
 Now using project "review" on server "https://api.ocp4.example.com:6443".
 ...output omitted...

Create the mysql8:1 image stream tag from the registry.ocp4.example.com:8443/rhel9/mysql-80:1-228 image. Enable image stream resolution for the mysql8 image stream so that Kubernetes resources in the current project can use it.
1. Use the oc create istag command to create the image stream and the image stream tag.
```
 [student@workstation ~]$ oc create istag mysql8:1 \
   --from-image registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
 imagestreamtag.image.openshift.io/mysql8:1 created
```
2. Use the oc set image-lookup command to enable image lookup resolution.
```
 [student@workstation ~]$ oc set image-lookup mysql8
 imagestream.image.openshift.io/mysql8 image lookup updated
```
3. Run the oc set image-lookup command without any arguments to verify your work.
```
 [student@workstation ~]$ oc set image-lookup
 NAME    LOCAL
 mysql8  true
```

Create the dbparams secret.

 [student@workstation ~]$ oc create secret generic dbparams \
   --from-literal user=operator1 --from-literal password=redhat123 \
   --from-literal database=quotesdb
 secret/dbparams created

Create the quotesdb deployment from the mysql8:1 image stream tag. Set the number of replicas to zero, to prevent OpenShift from deploying the database before you finish its configuration. Ignore the warning message.
```
 [student@workstation ~]$ oc create deployment quotesdb --image mysql8:1 \
   --replicas 0
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb created
```

Add an image trigger to the quotesdb deployment.

Retrieve the name of the container from the quotesdb deployment.

 [student@workstation ~]$ oc get deployment quotesdb -o wide
 NAME       READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS ...
 quotesdb   0/0     0            0           11s   mysql8     ...

Use the oc set triggers command to add the trigger for the mysql8:1 image stream tag to the mysql8 container. Ignore the warning message.

 [student@workstation ~]$ oc set triggers deployment/quotesdb \
   --from-image mysql8:1 --containers mysql8
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb triggers updated

Add environment variables to the quotesdb deployment from the dbparams secret. Add the MYSQL_ prefix to each variable name. Ignore the warning message.

 [student@workstation ~]$ oc set env deployment/quotesdb \
   --from secret/dbparams --prefix MYSQL_
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb updated

Add a 2 GiB persistent volume to the quotesdb deployment. Use the lvms-vg1 storage class. Inside the pods, mount the volume under the /var/lib/mysql directory. Ignore the warning message.

 [student@workstation ~]$ oc set volumes deployment/quotesdb --add \
   --claim-class lvms-vg1 --claim-size 2Gi --mount-path /var/lib/mysql
 info: Generated volume name: volume-n7xpd
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/quotesdb volume updated

Start the database by scaling up the quotesdb deployment to one replica.

Scale up the deployment.

 [student@workstation ~]$ oc scale deployment/quotesdb --replicas 1
 deployment.apps/quotesdb scaled

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                       READY   STATUS    RESTARTS   AGE
 quotesdb-99f9b4ff8-ggs7z   1/1     Running   0          4s
```

Create the quotesdb service for the quotesdb deployment. The database server is listening on port 3306.

Use the oc expose deployment command to create the service.

 [student@workstation ~]$ oc expose deployment quotesdb --port 3306
 service/quotesdb exposed

Verify that OpenShift associates the IP address of the MySQL server with the endpoint. The endpoint IP address on your system probably differs.

 [student@workstation ~]$ oc describe service quotesdb
 Name:              quotesdb
 Namespace:         review
 ...output omitted...
 TargetPort:        3306/TCP
 Endpoints:         10.8.0.123:3306
 Session Affinity:  None
 Events:

Create the frontend deployment from the registry.ocp4.example.com:8443/redhattraining/famous-quotes:2-42 image. Set the number of replicas to zero, to prevent OpenShift from deploying the application before you finish its configuration. Ignore the warning message.
```
[student@workstation ~]$ oc create deployment frontend \
  --image registry.ocp4.example.com:8443/redhattraining/famous-quotes:2-42 \
  --replicas 0
Warning: would violate PodSecurity "restricted:v1.24":
...output omitted...
deployment.apps/frontend created
```

Add environment variables to the frontend deployment from the dbparams secret, and add the QUOTES_HOSTNAME variable with the quotesdb value.

Add the variables from the dbparams secret. Add the QUOTES_ prefix to each variable name. Ignore the warning message.

 [student@workstation ~]$ oc set env deployment/frontend \
   --from secret/dbparams --prefix QUOTES_
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/frontend updated

Declare the QUOTES_HOSTNAME variable. Ignore the warning message.

 [student@workstation ~]$ oc set env deployment/frontend QUOTES_HOSTNAME=quotesdb
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/frontend updated

Start the application by scaling up the frontend deployment to one replica.

Scale up the deployment.

 [student@workstation ~]$ oc scale deployment/frontend --replicas 1
 deployment.apps/frontend scaled

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.

 [student@workstation ~]$ oc get pods
 NAME                       READY   STATUS    RESTARTS   AGE
 frontend-86cdd7c7bf-hpnwz  1/1     Running   0          44s
 quotesdb-99f9b4ff8-ggs7z   1/1     Running   0          2m11s

Expose the frontend deployment so that the application is accessible from outside the cluster. The web application is listening on port 8000.

Create the frontend service for the frontend deployment.

 [student@workstation ~]$ oc expose deployment frontend --port 8000
 service/frontend exposed

Create the route.

 [student@workstation ~]$ oc expose service frontend
 route.route.openshift.io/frontend exposed

Retrieve the application URL from the route.

 [student@workstation ~]$ oc get route
 NAME       HOST/PORT                               PATH   SERVICES ...
 frontend   frontend-review.apps.ocp4.example.com          frontend ...

Use the curl command to test the application.

 [student@workstation ~]$ curl http://frontend-review.apps.ocp4.example.com
 
     
         Quotes
     
     

         Quote List

             

                     1: When words fail, music speaks.
 - William Shakespeare
 
 ...output omitted...

Hide Solution

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade compreview-deploy

Finish

[student@workstation ~]$ lab finish compreview-deploy

Lab: Manage Application Updates

Syarif — Wed, 12 Jul 2023 11:23:44 GMT

Update two live applications to their latest releases as identified by non-floating tags.

Outcomes

You should be able to configure Deployment objects with images and triggers, and configure image stream tags and aliases.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the updates-review project and deploys two applications, app1 and app2, in that project.

The command creates the /home/student/DO180/labs/updates-review/resources.txt file. The resources.txt file contains the name of the images that you use during the exercise. You can use the file to copy and paste these image names.

[student@workstation ~]$ lab start updates-review

Procedure 7.5. Instructions

The API URL of your OpenShift cluster is https://api.ocp4.example.com:6443, and the oc command is already installed on your workstation machine.

Log in to the OpenShift cluster as the developer user with the developer password. Use the updates-review project for your work.

Your team created the app1 deployment in the updates-review project from the registry.ocp4.example.com:8443/redhattraining/php-ssl:latest container image. Recently, a developer in your organization pushed a new version of the image and then reassigned the latest tag to that version.

Reconfigure the app1 deployment to use the 1-222 static tag instead of the latest floating tag, to prevent accidental redeployment of your application with untested image versions that your developers can publish at any time.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the updates-review project as the active project.

 [student@workstation ~]$ oc project updates-review
 ...output omitted...

Verify that the app1 deployment uses the latest tag. Retrieve the container name.

 [student@workstation ~]$ oc get deployment/app1 -o wide
 NAME  READY ...  CONTAINERS  IMAGES ...
 app1  1/1   ...  php-ssl     registry...:8443/redhattraining/php-ssl:latest ...

In the Deployment object, change the image to registry.ocp4.example.com:8443/redhattraining/php-ssl:1-222. Ignore the warning message.

 [student@workstation ~]$ oc set image deployment/app1 \
   php-ssl=registry.ocp4.example.com:8443/redhattraining/php-ssl:1-222
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/app1 image updated

Verify your work.

 [student@workstation ~]$ oc get deployment/app1 -o wide
 NAME   READY ... CONTAINERS  IMAGES ...
 app1   1/1   ... php-ssl     registry...:8443/redhattraining/php-ssl:1-222 ...

Hide Solution

The app2 deployment is using the php-ssl:1 image stream tag, which is an alias for the php-ssl:1-222 image stream tag.

Enable image triggering for the app2 deployment, so that whenever the php-ssl:1 image stream tag changes, OpenShift rolls out the application. You test your configuration in a later step, when you reassign the php-ssl:1 alias to a new image stream tag.

Retrieve the container name from the Deployment object.

 [student@workstation ~]$ oc get deployment/app2 -o wide
 NAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS  ...
 app2   1/1     1            1           21m   php-ssl     ...

Add the image trigger to the Deployment object. Ignore the warning message.

 [student@workstation ~]$ oc set triggers deployment/app2 \
   --from-image php-ssl:1 --containers php-ssl
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/app2 triggers updated

Verify your work.

 [student@workstation ~]$ oc set triggers deployment/app2
 NAME              TYPE    VALUE                AUTO
 deployments/app2  config                       true
 deployments/app2  image   php-ssl:1 (php-ssl)  true

Hide Solution

A new image version, registry.ocp4.example.com:8443/redhattraining/php-ssl:1-234, is available in the container registry. Your QA team tested and approved that version. It is ready for production.

Create the php-ssl:1-234 image stream tag that points to the new image. Move the php-ssl:1 image stream tag alias to the new php-ssl:1-234 image stream tag. Verify that the app2 application redeploys.

Create the php-ssl:1-234 image stream tag.

 [student@workstation ~]$ oc create istag php-ssl:1-234 \
   --from-image registry.ocp4.example.com:8443/redhattraining/php-ssl:1-234
 imagestreamtag.image.openshift.io/php-ssl:1-234 created

Move the php-ssl:1 alias to the new php-ssl:1-234 image stream tag.

 [student@workstation ~]$ oc tag --alias php-ssl:1-234 php-ssl:1
 Tag php-ssl:1 set up to track php-ssl:1-234.

Verify that the app2 application rolls out. The names of the replica sets on your system probably differ.

 [student@workstation ~]$ oc describe deployment/app2
 Name:                   app2
 Namespace:              updates-review
 ...output omitted...
 Events:
   Type    ...  Age         Message
   ----         ----        -------
   Normal  ...  33m    ...  Scaled up replica set app2-7dd589f6d5 to 1
   Normal  ...  3m30s  ...  Scaled up replica set app2-7bf5b7787 to 1
   Normal  ...  3m28s  ...  Scaled down replica set app2-7dd589f6d5 to 0 from 1

Hide Solution

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade updates-review

Finish

[student@workstation ~]$ lab finish updates-review

Guided Exercise: Automatic Image Updates with OpenShift Image Change Triggers

Syarif — Wed, 12 Jul 2023 11:22:39 GMT

Update an application that references container images indirectly though image streams.

Outcomes

Add an image trigger to a deployment.
Modify an image stream tag to point to a new image.
Watch the rollout of the application.
Roll back a deployment to the previous image.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the updates-triggers project and deploys a web application with 10 replicas.

The command creates the /home/student/DO180/labs/updates-triggers/resources.txt file. The resources.txt file contains the name of the images and some commands that you use during the exercise. You can use the file to copy and paste these image names and commands.

[student@workstation ~]$ lab start updates-triggers

Procedure 7.4. Instructions

Log in to the OpenShift cluster as the developer user with the developer password. Use the updates-triggers project.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the updates-triggers project as the active project.

 [student@workstation ~]$ oc project updates-triggers
 ...output omitted...

Inspect the versioned-hello image stream that the lab command created.
1. Verify that the lab command enabled the local lookup policy for the versioned-hello image stream.
```
 [student@workstation ~]$ oc set image-lookup
 NAME             LOCAL
 versioned-hello  true
```
2. Verify that the lab command created the versioned-hello:1 image stream tag. The image stream tag refers to the image in the classroom registry by its SHA ID.
  
  NOTE
  
  To improve readability, the instructions truncate the SHA-256 strings.
  
  On your system, the commands return the full SHA-256 strings. Also, you must type the full SHA-256 string, to provide such a parameter to a command.
```
 [student@workstation ~]$ oc get istag
 NAME               IMAGE REFERENCE ...
 versioned-hello:1  ...:8443/redhattraining/versioned-hello@sha256:66e0...105e ...
```
3. Verify that the lab command created the versioned-hello:1 image stream tag from the registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-123 image.
```
 [student@workstation ~]$ oc get istag versioned-hello:1 \
   -o jsonpath='{.tag.from.name}{"\n"}'
 registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-123
```
Inspect the Deployment object that the lab command created. Verify that the application is available from outside the cluster.
1. List the Deployment objects. The version deployment retrieved the SHA image ID from the versioned-hello:1 image stream tag. The Deployment object includes a container named versioned-hello. You use that information in a later step, when you configure the trigger.
```
 [student@workstation ~]$ oc get deployment -o wide
 NAME     READY ... CONTAINERS        IMAGES ...
 version  10/10 ... versioned-hello   .../versioned-hello@sha256:66e0...105e ...
```
2. Open a new terminal.
3. Run the /home/student/DO180/labs/updates-triggers/curl_loop.sh script that the lab command prepared. The script sends web requests to the application in a loop. Leave the script running and do not interrupt it.
```
 [student@workstation ~]$ /home/student/DO180/labs/updates-triggers/curl_loop.sh
 Hi!
 Hi!
 Hi!
 Hi!
 ...output omitted...
```

Add an image trigger to the Deployment object.

Switch back to the first terminal window, and then use the oc set triggers command to add the trigger for the versioned-hello:1 image stream tag to the versioned-hello container. Ignore the warning message.

 [student@workstation ~]$ oc set triggers deployment/version \
   --from-image versioned-hello:1 --containers versioned-hello
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/version triggers updated

Review the definition of the trigger from the image.openshift.io/triggers annotation.

 [student@workstation ~]$ oc get deployment version \
   -o jsonpath='{.metadata.annotations.image\.openshift\.io/triggers}' | jq .
 [
   {
     "from": {
       "kind": "ImageStreamTag",
       "name": "versioned-hello:1"
     },
     "fieldPath": "spec.template.spec.containers[?(@.name==\"versioned-hello\")].image"
   }
 ]

Update the versioned-hello:1 image stream tag to point to the 1-125 tag of the registry.ocp4.example.com:8443/redhattraining/versioned-hello image. Watch the output of the curl_loop.sh script to verify that the Deployment object automatically rolls out.
1. Use the oc tag command to update the versioned-hello:1 tag.
```
 [student@workstation ~]$ oc tag \
   registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-125 \
   versioned-hello:1
 Tag versioned-hello:1 set to registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-125.
```
2. Changing the image stream tag triggered a rolling update. Watch the output of the curl_loop.sh script in the second terminal.
  
  Before the update, only pods that use the earlier version of the image reply. During the rolling updates, both old and new pods respond. After the update, only pods that run the latest version of the image reply. The following output probably differs on your system.
```
 ...output omitted...
 Hi!
 Hi!
 Hi!
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 ...output omitted...
```
  Do not stop the script.

Inspect the Deployment object and the image stream.

List the version deployment and notice that the image changed.

 [student@workstation ~]$ oc get deployment version -o wide
 NAME     READY ... CONTAINERS        IMAGES ...
 version  10/10 ... versioned-hello   .../versioned-hello@sha256:834d...fcb4 ...

Display the details of the versioned-hello image stream. The versioned-hello:1 image stream tag points to the image with the same SHA ID as in the Deployment object.

Notice that the preceding image is still available. In the following step, you roll back to that image by specifying its SHA ID.

 [student@workstation ~]$ oc describe is versioned-hello
 Name:           versioned-hello
 Namespace:      updates-triggers
 ...output omitted...

 1
   tagged from registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-125

   * registry.ocp4.example.com:8443/.../versioned-hello@sha256:834d...fcb4
       6 minutes ago
     registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e
       37 minutes ago

Roll back the Deployment object by reverting the versioned-hello:1 image stream tag.
1. Use the oc tag command. For the source image, copy and paste the old image name and the SHA ID from the output of the preceding command.
```
 [student@workstation ~]$ oc tag \
 registry.ocp4.example.com:8443/redhattraining/versioned-hello@sha256:66e0...105e \
 versioned-hello:1
 Tag versioned-hello:1 set to registry.ocp4.example.com:8443/redhattraining/versioned-hello@sha256:66e0...105e.
```
2. Watch the output of the curl_loop.sh script in the second terminal. The pods that run the v1.0 version of the application are responding again. The following output probably differs on your system.
```
 ...output omitted...
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi!
 Hi!
 ...output omitted...
```
  Press Ctrl+C to quit the script. Close that second terminal when done.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish updates-triggers

Guided Exercise: Reproducible Deployments with OpenShift Image Streams

Syarif — Wed, 12 Jul 2023 11:21:03 GMT

Deploy an application that references container images indirectly by using image streams.

Outcomes

You should be able to create image streams and image stream tags, and deploy applications that use image stream tags.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the updates-imagestreams project and the /home/student/DO180/labs/updates-imagestreams/resources.txt file. The resources.txt file contains the name of the images and some commands that you use during the exercise. You can use the file to copy and paste these image names and commands.

[student@workstation ~]$ lab start updates-imagestreams

Procedure 7.3. Instructions

Log in to the OpenShift cluster as the developer user with the developer password. Use the updates-imagestreams project.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the updates-imagestreams project as the active project.

 [student@workstation ~]$ oc project updates-imagestreams
 ...output omitted...

Create the versioned-hello image stream and the v1.0 image stream tag from the registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0 image.

Use the oc create is command to create the image stream.

 [student@workstation ~]$ oc create is versioned-hello
 imagestream.image.openshift.io/versioned-hello created

Use the oc create istag command to create the image stream tag.

 [student@workstation ~]$ oc create istag versioned-hello:v1.0 \
   --from-image registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
 imagestreamtag.image.openshift.io/versioned-hello:v1.0 created

Enable image stream resolution for the versioned-hello image stream so that Kubernetes resources in the current project can use it.
1. Use the oc set image-lookup command to enable image lookup resolution.
```
 [student@workstation ~]$ oc set image-lookup versioned-hello
 imagestream.image.openshift.io/versioned-hello image lookup updated
```
2. Run the oc set image-lookup command without any arguments to verify your work.
```
 [student@workstation ~]$ oc set image-lookup
 NAME             LOCAL
 versioned-hello  true
```

Review the image stream and confirm that the image stream tag refers to the source image by its SHA ID. Verify that the source image in the registry.ocp4.example.com:8443 registry has the same SHA ID.

Retrieve the details of the versioned-hello image stream.

NOTE

To improve readability, the instructions truncate the SHA-256 strings.

 [student@workstation ~]$ oc describe is versioned-hello
 Name:           versioned-hello
 Namespace:      updates-imagestreams
 Created:        7 minutes ago
 ...output omitted...

 v1.0
   tagged from registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0

   * registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e
       7 minutes ago

Use the oc image info command to query the image from the classroom container registry. The SHA image ID is the same as the one from the image stream tag.

 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
 Name:          registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
 Digest:        sha256:66e0...105e
 Media Type:    application/vnd.docker.distribution.manifest.v2+json
 ...output omitted...

Create a deployment named version that uses the versioned-hello:v1.0 image stream tag.

Use the oc create deployment command to create the object. Ignore the warning message.

 [student@workstation ~]$ oc create deployment version --image versioned-hello:v1.0
 Warning: would violate PodSecurity "restricted:v1.24":
  ...output omitted...
 deployment.apps/version created

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                       READY   STATUS    RESTARTS   AGE
 version-744bf7694b-bzhd2   1/1     Running   0          2m11s
```

Confirm that both the deployment and the pod refer to the image by its SHA ID.
1. Retrieve the image that the deployment uses. The deployment refers to the image from the source registry by its SHA ID. The v1.0 image stream tag also points to that SHA image ID.
```
 [student@workstation ~]$ oc get deployment -o wide
 ... IMAGES ...
 ... registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e ...
```
2. Retrieve the image that the pod is using. The pod is also referring to the image by its SHA ID.
```
 [student@workstation ~]$ oc get pod version-744bf7694b-bzhd2 \
   -o jsonpath='{.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/redhattraining/versioned-hello@sha256:66e0...105e
```

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish updates-imagestreams

Guided Exercise: Update Application Image and Settings

Syarif — Wed, 12 Jul 2023 11:19:21 GMT

Update the manifests of a database and a web application while minimizing interruption of service to their users.

Outcomes

You should be able to pause, update, and resume a deployment, and roll back a failing application.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the updates-rollout-db project and deploys a MySQL database in that project. It creates the updates-rollout-web project and then deploys a web application with 10 replicas.

The command creates the /home/student/DO180/labs/updates-rollout/resources.txt file. The resources.txt file contains the name of the images and some commands that you use during the exercise. You can use the file to copy and paste these image names and commands.

[student@workstation ~]$ lab start updates-rollout

Procedure 7.2. Instructions

Log in to the OpenShift cluster as the developer user with the developer password. Use the updates-rollout-db project.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the updates-rollout-db project as the active project.

 [student@workstation ~]$ oc project updates-rollout-db
 ...output omitted...

Review the resources that the lab command created. Confirm that you can connect to the database. The MySQL database uses ephemeral storage.
1. List the Deployment object and confirm that the pod is available. Retrieve the name of the container. You use that information when you update the container image in another step.
```
 [student@workstation ~]$ oc get deployment -o wide
 NAME   READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS ...
 mydb   1/1     0            1           17m   mysql-80   ...
```
2. List the pods and confirm that the pod is running. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pod
 NAME                    READY   STATUS    RESTARTS   AGE
 mydb-5c79866d48-5xzkk   1/1     Running   0          18m
```
3. Retrieve the name of the image that the pod is using. The pod is using the rhel9/mysql-80 image version 1-224. Replace the pod name with your own from the previous step.
```
 [student@workstation ~]$ oc get pod mydb-5c79866d48-5xzkk \
   -o jsonpath='{.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/rhel9/mysql-80:1-224
```
  The classroom setup copied that image from the Red Hat Ecosystem Catalog. The original image is registry.redhat.io/rhel9/mysql-80.
4. Confirm that you can connect to the database system by listing the available databases. Run the mysql command from inside the pod and connect as the operator1 user by using test as the password.
```
 [student@workstation ~]$ oc rsh mydb-5c79866d48-5xzkk \
   mysql --user=operator1 --password=test -e "SHOW DATABASES"
 mysql: [Warning] Using a password on the command line interface can be insecure.
 +--------------------+
 | Database           |
 +--------------------+
 | information_schema |
 | performance_schema |
 | quotes             |
 +--------------------+
```

You must implement several updates to the Deployment object. Pause the deployment to prevent OpenShift from rolling out the application for each modification that you make. After you pause the deployment, change the password for the operator1 database user, update the container image, and then resume the deployment.

Pause the mydb deployment. Ignore the warning message.

 [student@workstation ~]$ oc rollout pause deployment/mydb
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/mydb paused

Change the password of the operator1 database user to redhat123. To change the password, update the MYSQL_PASSWORD environment variable in the pod template of the Deployment object. Ignore the warning message.
```
 [student@workstation ~]$ oc set env deployment/mydb MYSQL_PASSWORD=redhat123
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/mydb updated
```

Because the Deployment object is paused, confirm that the new password is not yet active. To do so, rerun the mysql command by using the current password. The database connection succeeds.

 [student@workstation ~]$ oc rsh mydb-5c79866d48-5xzkk \
   mysql --user=operator1 --password=test -e "SHOW DATABASES"
 mysql: [Warning] Using a password on the command line interface can be insecure.
 +--------------------+
 | Database           |
 +--------------------+
 | information_schema |
 | performance_schema |
 | quotes             |
 +--------------------+

Update the MySQL container image to the 1-228 version. Ignore the warning message.

 [student@workstation ~]$ oc set image deployment/mydb \
   mysql-80=registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/mydb image updated

Because the Deployment object is paused, confirm that the pod still uses the 1-224 image version.

 [student@workstation ~]$ oc get pod mydb-5c79866d48-5xzkk \
   -o jsonpath='{.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/rhel9/mysql-80:1-224

Resume the mydb deployment. Ignore the warning message.

 [student@workstation ~]$ oc rollout resume deployment/mydb
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/mydb resumed

Confirm that the new rollout completes by waiting for the new pod to be running. The name of the pod on your system probably differs.

 [student@workstation ~]$ oc get pods
 NAME                   READY   STATUS    RESTARTS   AGE
 mydb-dd5dcbddb-rmf85   1/1     Running   0          2m2s

Verify that OpenShift applied all your modifications to the Deployment object.

Retrieve the name of the image that the new pod is using. In the following command, use the name of the new pod as a parameter to the oc get pod command. The pod is now using the 1-228 image version.
```
 [student@workstation ~]$ oc get pod mydb-dd5dcbddb-rmf85 \
   -o jsonpath='{.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
```

Confirm that you can connect to the database system by using the new password, redhat123, for the operator1 database user.

 [student@workstation ~]$ oc rsh mydb-dd5dcbddb-rmf85 \
   mysql --user=operator1 --password=redhat123 -e "SHOW DATABASES"
 mysql: [Warning] Using a password on the command line interface can be insecure.
 +--------------------+
 | Database           |
 +--------------------+
 | information_schema |
 | performance_schema |
 | quotes             |
 +--------------------+

In the second part of the exercise, you perform a rolling update of a replicated web application. Use the updates-rollout-web project and review the resources that the lab command created.

Set the updates-rollout-web project as the active project.

 [student@workstation ~]$ oc project updates-rollout-web
 ...output omitted...

List the Deployment object and confirm that the pods are available. Retrieve the name of the containers. You use that information when you update the container image in another step.

 [student@workstation ~]$ oc get deployment -o wide
 NAME      READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS      ...
 version   10/10   10           10          32m   versioned-hello ...

List the ReplicaSet objects. Because OpenShift did not yet perform rolling updates, only one ReplicaSet object exists. The name of the ReplicaSet object on your system probably differs.
```
 [student@workstation ~]$ oc get replicaset
 NAME                 DESIRED   CURRENT   READY   AGE
 version-7bfff6b5b4   10        10        10      11m
```

Retrieve the name and version of the image that the ReplicaSet object uses to deploy the pods. The pods are using the redhattraining/versioned-hello image version v1.0.

 [student@workstation ~]$ oc get replicaset version-7bfff6b5b4 \
   -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0

Confirm that the version deployment includes a readiness probe. The probe performs an HTTP GET request on port 8080.

 [student@workstation ~]$ oc get deployment version \
   -o jsonpath='{.spec.template.spec.containers[0].readinessProbe}' | jq .
 {
   "failureThreshold": 3,
   "httpGet": {
     "path": "/",
     "port": 8080,
     "scheme": "HTTP"
   },
   "initialDelaySeconds": 3,
   "periodSeconds": 10,
   "successThreshold": 1,
   "timeoutSeconds": 1
 }

To watch the rolling update that you cause in a following step, open a new terminal window and then run the ~/DO180/labs/updates-rollout/curl_loop.sh script that the lab command prepared. The script sends web requests to the application in a loop.
1. Open a new terminal.
2. Run the /home/student/DO180/labs/updates-rollout/curl_loop.sh script. Leave the script running and do not interrupt it.
```
 [student@workstation ~]$ /home/student/DO180/labs/updates-rollout/curl_loop.sh
 Hi!
 Hi!
 Hi!
 Hi!
 ...output omitted...
```
Change the container image of the version deployment. The new application version creates a web page with a different message.
1. Switch back to the first terminal window, and then use the oc set image command to update the deployment. Ignore the warning message.
```
 [student@workstation ~]$ oc set image deployment/version \
 versioned-hello=registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.1
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/version image updated
```
2. Changing the image caused a rolling update. Watch the output of the curl_loop.sh script in the second terminal.
  
  Before the update, only pods that run the v1.0 version of the application reply. During the rolling updates, both old and new pods are responding. After the update, only pods that run the v1.1 version of the application reply. The following output probably differs on your system.
```
 ...output omitted...
 Hi!
 Hi!
 Hi!
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 ...output omitted...
```
  Do not stop the script.
Confirm that the rollout process is successful. List the ReplicaSet objects and verify that the new object uses the new image version.
1. Use the oc rollout status command to confirm that the rollout process is successful.
```
 [student@workstation ~]$ oc rollout status deployment/version
 deployment "version" successfully rolled out
```
2. List the ReplicaSet objects. The initial object scaled down to zero pods. The new ReplicaSet object scaled up to 10 pods. The names of the ReplicaSet objects on your system probably differ.
```
 [student@workstation ~]$ oc get replicaset
 NAME                 DESIRED   CURRENT   READY   AGE
 version-7bfff6b5b4   0         0         0       28m
 version-b7fddfc8c    10        10        10      3m40s
```
3. Retrieve the name and version of the image that the new ReplicaSet object uses. This image provides the new version of the application.
```
 [student@workstation ~]$ oc get replicaset version-b7fddfc8c \
   -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.1
```
Roll back the version deployment.
1. Use the oc rollout undo command to roll back to the initial application version. Ignore the warning message.
```
 [student@workstation ~]$ oc rollout undo deployment/version
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/version rolled back
```
2. Watch the output of the curl_loop.sh script in the second terminal. The pods that run the v1.0 version of the application are responding again. The following output probably differs on your system.
```
 ...output omitted...
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi!
 Hi! v1.1
 Hi! v1.1
 Hi!
 Hi!
 Hi!
 ...output omitted...
```
  Press Ctrl+C to quit the script. Close that second terminal when done.
3. List the ReplicaSet objects. The initial object scaled up to 10 pods. The object for the new application version scaled down to zero pods.
```
 [student@workstation ~]$ oc get replicaset
 NAME                 DESIRED   CURRENT   READY   AGE
 version-7bfff6b5b4   10        10        10      52m
 version-b7fddfc8c    0         0         0       27m
```

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish updates-rollout

Guided Exercise: Container Image Identity and Tags

Syarif — Wed, 12 Jul 2023 11:18:32 GMT

Update an application by changing its deployment to reference a newer image tag, and find the hashes of the old and new application images.

Outcomes

You should be able to inspect container images, list images of containers that run on compute nodes, and deploy applications by using image tags or SHA IDs.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the updates-ids project and the /home/student/DO180/labs/updates-ids/resources.txt file. The resources.txt file contains the name of the images and some commands that you use during the exercise. You can use the file to copy and paste these image names and commands.

[student@workstation ~]$ lab start updates-ids

Procedure 7.1. Instructions

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the updates-ids project as the active project.

 [student@workstation ~]$ oc project updates-ids
 ...output omitted...

Inspect the two versions of the registry.ocp4.example.com:8443/ubi8/httpd-24 image from the classroom container registry. The classroom setup copied that image from the Red Hat Ecosystem Catalog. The original image is registry.access.redhat.com/ubi8/httpd-24.
1. Use the oc image info command to inspect the image version that the 1-209 tag references. Notice the unique SHA ID that identifies the image version.
  
  NOTE
  
  To improve readability, the instructions truncate the SHA-256 strings.
  
  On your system, the commands return the full SHA-256 strings. Also, you must type the full SHA-256 string, to provide such a parameter to a command.
```
 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
 Name:          registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
 Digest:        sha256:b1e3...f876
 ...output omitted...
```
2. Inspect the image version that the 1-215 tag references. Notice that the SHA ID, or digest, differs from the preceding image version.
```
 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
 Name:          registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
 Digest:        sha256:91ad...fd83
 ...output omitted...
```
3. For inspecting images, you can also use the skopeo inspect command. The output format differs from the oc image info command, although both commands report similar data.
  
  Log in to the registry as the developer user with the developer password by using the skopeo login command. Then, use the skopeo inspect command to inspect the 1-215 image tag.
```
 [student@workstation ~]$ skopeo login registry.ocp4.example.com:8443 -u developer
 Password:
 Login Succeeded!
```
```
 [student@workstation ~]$ skopeo inspect \
   docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
 {
     "Name": "registry.ocp4.example.com:8443/ubi8/httpd-24",
     "Digest": "sha256:91ad...fd83",
     "RepoTags": [
         "1-209",
         "1-215"
     ],
 ...output omitted...
 }
```
  The skopeo inspect command also shows other existing image tags.

Deploy an application from the image version that the 1-209 tag references.

Use the oc create deployment command to deploy the application. Set the name of the deployment to httpd1. Ignore the warning message.

 [student@workstation ~]$ oc create deployment httpd1 \
   --image registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/httpd1 created

Wait for the pod to start, and then retrieve the name of the cluster node that runs it. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods -o wide
 NAME                     READY  STATUS   RESTARTS  AGE  IP          NODE     ...
 httpd1-6dff796d99-pm2x6  1/1    Running  0         19s  10.8.0.104  master01 ...
```

Retrieve the name of the container that is running inside the pod. The crictl ps command that you run in a following step takes the container name as an argument.

 [student@workstation ~]$ oc get deployment httpd1 -o wide
 NAME     READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS  ...
 httpd1   1/1     1            1           1m10s   httpd-24    ...

Access the cluster node and then retrieve the image that the container is using.
1. You must log in as the admin user to access the cluster node. Use the redhatocp password.
```
 [student@workstation ~]$ oc login -u admin -p redhatocp
 Login successful.
 ...output omitted...
```
2. Use the oc debug node command to access the cluster node.
```
 [student@workstation ~]$ oc debug node/master01
 Temporary namespace openshift-debug-flz4d is created for debugging node...
 Starting pod/master01-debug ...
 To use host binaries, run `chroot /host`
 Pod IP: 192.168.50.10
 If you don't see a command prompt, try pressing enter.
```
3. In the remote shell, run the chroot /host command.
```
 sh-4.4# chroot /host
 sh-4.4#
```
4. Use the crictl ps command to confirm that the httpd-24 container is running. Add the -o yaml option to display the container details in YAML format.
```
 sh-4.4# crictl ps --name httpd-24 -o yaml
 containers:
 - annotations:
 ...output omitted...
   image:
     annotations: {}
     image: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
   imageRef: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
   labels:
 ...output omitted...
   state: CONTAINER_RUNNING
```
  Notice that the command refers to the image by its SHA ID, and not by the tag that you specified when you created the deployment resource.
5. Use the crictl images command to list the locally available images on the node. The registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 is in that list, because the local container engine pulled it when you deployed the httpd1 application.
  
  NOTE
  
  The IMAGE ID column displays the local image identifier that the container engine assigns to the image. This identifier is not related to the SHA image ID that the container registry assigned to the image.
  
  Most crictl commands, such as crictl images or crictl rmi, accept a local image identifier instead of the full image name. For example, you can run the crictl images 8ee59251acc93 command as a short version of the crictl images registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 command.
```
 sh-4.4# crictl images
 IMAGE                                           TAG     IMAGE ID           SIZE
 quay.io/openshift-release-dev/ocp-release         d52324cb88017      444MB
 quay.io/openshift-release-dev/ocp-v4.0-art-dev    22e6e45df32af      468MB
 quay.io/openshift-release-dev/ocp-v4.0-art-dev    e798432938c49      503MB
 quay.io/openshift-release-dev/ocp-v4.0-art-dev    3ca084e53b321      873MB
 ...output omitted...
 registry.ocp4.example.com:8443/ubi8/httpd-24    1-209   8ee59251acc93      461MB
 ...output omitted...
```
6. The preceding crictl images command does not display the SHA image IDs by default. Rerun the command and add the --digests option to display the SHA IDs. Also add the local image ID to the command to limit the output to the registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 image.
  
  The command reports only the first characters of the SHA image ID. These characters match the SHA ID of the image that the httpd-24 container is using. Therefore, the httpd-24 container is using the expected image.
```
 sh-4.4# crictl images --digests 8ee59251acc93
 IMAGE                                        TAG   DIGEST        IMAGE ID      ...
 registry.ocp4.example.com:8443/ubi8/httpd-24 1-209 b1e3c572516d1 8ee59251acc93 ...
```
7. Disconnect from the cluster node.
```
 sh-4.4# exit
 exit
 sh-4.4# exit
 exit

 Removing debug pod ...
 Temporary namespace openshift-debug-flz4d was removed.
 [student@workstation ~]$
```

 [student@workstation ~]$ oc login -u developer -p developer
 Login successful.
 ...output omitted...

Rerun the oc image info command to retrieve the SHA ID of the image version that the 1-209 tag references. Specify the JSON format for the command output. Parse the JSON output with the jq -r command to retrieve the value of the .digest object. Export the SHA ID as the $IMAGE environment variable.
```
 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 -o json | \
   jq -r .digest
 sha256:b1e3...f876
```
```
 [student@workstation ~]$ IMAGE=sha256:b1e3...f876
```

Use the oc create deployment command to deploy the application. Set the name of the deployment to httpd2. Ignore the warning message.

 [student@workstation ~]$ oc create deployment httpd2 \
   --image registry.ocp4.example.com:8443/ubi8/httpd-24@$IMAGE
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/httpd2 created

Confirm that the new deployment refers to the image version by its SHA ID.

 [student@workstation ~]$ oc get deployment httpd2 -o wide
 NAME     READY  ...  CONTAINERS   IMAGES ...
 httpd2   1/1    ...  httpd-24     registry.../ubi8/httpd-24@sha256:b1e3...f876 ...

Update the httpd2 application by using a more recent image version.

In the httpd2 deployment, update the httpd-24 container to use the image version that the 1-215 tag references. Ignore the warning message.

 [student@workstation ~]$ oc set image deployment/httpd2 \
   httpd-24=registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/httpd2 image updated

Confirm that the deployment refers to the new image version.

 [student@workstation ~]$ oc get deployment httpd2 -o wide
 NAME     READY   ...    IMAGES ...
 httpd2   1/1     ...    registry.ocp4.example.com:8443/ubi8/httpd-24:1-215 ...

Confirm that the deployment finished redeploying the pod. You might have to rerun the command several times for the pod to report a Running status. The pod names probably differ on your system.

 [student@workstation ~]$ oc get pods
 NAME                      READY   STATUS    RESTARTS   AGE
 httpd1-6dff796d99-pm2x6   1/1     Running   0          118m
 httpd2-998d9b9b9-5859j    1/1     Running   0          21s

Inspect the pod to confirm that the container is using the new image. Replace the pod name with your own from the previous step.

 [student@workstation ~]$ oc get pod httpd2-998d9b9b9-5859j \
   -o jsonpath='{.spec.containers[0].image}{"\n"}'
 registry.ocp4.example.com:8443/ubi8/httpd-24:1-215

Add the latest tag to the image version that the 1-209 tag already references. Deploy an application from the image with the latest tag.

Use the skopeo login command to log in to the classroom container registry as the developer user. Use developer for the password.
```
 [student@workstation ~]$ skopeo login -u developer -p developer \
   registry.ocp4.example.com:8443
 Login Succeeded!
```

Use the skopeo copy command to add the latest tag to the image.

 [student@workstation ~]$ skopeo copy \
   docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 \
   docker://registry.ocp4.example.com:8443/ubi8/httpd-24:latest
 Getting image source signatures
 ...output omitted...
 Writing manifest to image destination
 Storing signatures

Use the oc image info command to confirm that both tags refer to the same image. The two commands report the same SHA image ID, which indicates that the tags point to the same image version.

 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
 Name:          registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
 Digest:        sha256:b1e3...f876
 ...output omitted...

 [student@workstation ~]$ oc image info \
   registry.ocp4.example.com:8443/ubi8/httpd-24:latest
 Name:          registry.ocp4.example.com:8443/ubi8/httpd-24:latest
 Digest:        sha256:b1e3...f876
 ...output omitted...

Use the oc create deployment command to deploy another application. Set the name of the deployment to httpd3. To confirm that by default the command selects the latest tag, do not provide the tag part in the image name. Ignore the warning message.
```
 [student@workstation ~]$ oc create deployment httpd3 \
   --image registry.ocp4.example.com:8443/ubi8/httpd-24
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/httpd3 created
```

Confirm that the pod is running. You might have to rerun the command several times for the pod to report a Running status. The pod names probably differ on your system.

 [student@workstation ~]$ oc get pods
 NAME                      READY   STATUS    RESTARTS   AGE
 httpd1-6dff796d99-pm2x6   1/1     Running   0          150m
 httpd2-998d9b9b9-5859j    1/1     Running   0          32m
 httpd3-85b978d758-fvqdr   1/1     Running   0          42s

Confirm that the pod is using the expected image. Notice that the SHA image ID corresponds to the image that the 1-209 tag references. You retrieved that SHA image ID in a preceding step when you ran the oc image info command.

 [student@workstation ~]$ oc describe pod httpd3-85b978d758-fvqdr
 ...output omitted...
 Containers:
   httpd-24:
     Container ID: cri-o://2cee...3a68
     Image:        registry.ocp4.example.com:8443/ubi8/httpd-24
     Image ID:     registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
 ...output omitted...

Assign the latest tag to a different image version. This operation simulates a developer who pushes a new version of an image and assigns the latest tag to that new image version.

Use the skopeo copy command to add the latest tag to the image version that the 1-215 tag already references. The command automatically removes the latest tag from the earlier image.

 [student@workstation ~]$ skopeo copy \
   docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-215 \
   docker://registry.ocp4.example.com:8443/ubi8/httpd-24:latest
 Getting image source signatures
 ...output omitted...
 Writing manifest to image destination
 Storing signatures

Log out from the classroom container registry.

 [student@workstation ~]$ skopeo logout registry.ocp4.example.com:8443
 Removed login credentials for registry.ocp4.example.com:8443

Even though the latest tag is now referencing a different image version, OpenShift does not redeploy the pods that are running with the previous image version.

Rerun the oc describe pod command to confirm that the pod still uses the preceding image.

 [student@workstation ~]$ oc describe pod httpd3-85b978d758-fvqdr
 ...output omitted...
 Containers:
   httpd-24:
     Container ID: cri-o://2cee...3a68
     Image:        registry.ocp4.example.com:8443/ubi8/httpd-24
     Image ID:     registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
 ...output omitted...

Scale the httpd3 deployment to two pods.

Use the oc scale command to add a new pod to the deployment.

 [student@workstation ~]$ oc scale deployment/httpd3 --replicas 2
 deployment.apps/httpd3 scaled

List the pods to confirm that two pods are running for the httpd3 deployment. The pod names probably differ on your system.

 [student@workstation ~]$ oc get pods
 httpd1-6dff796d99-pm2x6   1/1     Running   0          75m
 httpd2-998d9b9b9-5859j    1/1     Running   0          30m
 httpd3-85b978d758-f98jh   1/1     Running   0          54s
 httpd3-85b978d758-fvqdr   1/1     Running   0          11m

Retrieve the SHA image ID for the pod that the deployment initially created. The ID did not change. The container is still using the original image version.

 [student@workstation ~]$ oc describe pod httpd3-85b978d758-fvqdr
 ...output omitted...
 Containers:
   httpd-24:
     Container ID: cri-o://2cee...3a68
     Image:        registry.ocp4.example.com:8443/ubi8/httpd-24
     Image ID:     registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
 ...output omitted...

Retrieve the SHA image ID for the additional pod. Notice that the ID is different. The additional pod is using the image that the latest tag is currently referencing.
```
 [student@workstation ~]$ oc describe pod httpd3-85b978d758-f98jh
 ...output omitted...
 Containers:
   httpd-24:
     Container ID: cri-o://d254...c893
     Image:        registry.ocp4.example.com:8443/ubi8/httpd-24
     Image ID:     registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:91ad...fd83
 ...output omitted...
```
The state of the deployment is inconsistent. The two replicated pods use a different image version. Consequently, the scaled application might not behave correctly. Red Hat recommends that you use a less volatile tag than latest in production environments, or that you tightly control the tag assignments in your container registry.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish updates-ids

Lab: Configure Applications for Reliability

Syarif — Wed, 12 Jul 2023 11:17:07 GMT

Deploy and troubleshoot a reliable application that defines health probes, compute resource requests, and compute resource limits so it can run N instances per node; and configure a horizontal pod autoscaler that will scale to a maximum of N instances.

Outcomes

You should be able to add resource requests to a Deployment object, configure probes, and create a horizontal pod autoscaler resource.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the reliability-review project and deploys the longload application in that project.

[student@workstation ~]$ lab start reliability-review

Procedure 6.6. Instructions

The API URL of your OpenShift cluster is https://api.ocp4.example.com:6443, and the oc command is already installed on your workstation machine.

Use the reliability-review project for your work.

The longload application in the reliability-review project fails to start. Diagnose and then fix the issue. The application needs 512 MiB of memory to work.

After you fix the issue, you can confirm that the application works by running the ~/DO180/labs/reliability-review/curl_loop.sh script that the lab command prepared. The script sends requests to the application in a loop. For each request, the script displays the pod name and the application status. Press Ctrl+C to quit the script.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the reliability-review project as the active project.

 [student@workstation ~]$ oc project reliability-review
 ...output omitted...

List the pods in the project. The pod is in the Pending status. The name of the pod on your system probably differs.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 longload-64bf8dd776-b6rkz   0/1     Pending   0          8m1s

Retrieve the events for the pod. No compute node has enough memory to accommodate the pod.

 [student@workstation ~]$ oc describe pod longload-64bf8dd776-b6rkz
 Name:             longload-64bf8dd776-b6rkz
 Namespace:        reliability-review
 ...output omitted...
 Events:
   Type     Reason            Age   From               Message
   ----     ------            ----  ----               -------
   Warning  FailedScheduling  8m    default-scheduler  0/1 nodes are available: 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Review the resource requests for memory. The longload deployment requests 8 GiB of memory.

 [student@workstation ~]$ oc get deployment longload -o \
   jsonpath='{.spec.template.spec.containers[0].resources.requests.memory}{"\n"}'
 8Gi

Set the memory requests to 512 MiB. Ignore the warning message.

 [student@workstation ~]$ oc set resources deployment/longload \
   --requests memory=512Mi
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/longload resource requirements updated

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 longload-5897c9558f-cx4gt   1/1     Running   0          86s
```

Run the ~/DO180/labs/reliability-review/curl_loop.sh script to confirm that the application works.

 [student@workstation ~]$ ~/DO180/labs/reliability-review/curl_loop.sh
 1 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection refused
 2 longload-5897c9558f-cx4gt: app is still starting
 3 longload-5897c9558f-cx4gt: app is still starting
 4 longload-5897c9558f-cx4gt: app is still starting
 5 longload-5897c9558f-cx4gt: Ok
 6 longload-5897c9558f-cx4gt: Ok
 7 longload-5897c9558f-cx4gt: Ok
 8 longload-5897c9558f-cx4gt: Ok
 ...output omitted...

Press Ctrl+C to quit the script.

Hide Solution

When the application scales up, your customers complain that some requests fail. To replicate the issue, manually scale up the longload application to three replicas, and run the ~/DO180/labs/reliability-review/curl_loop.sh script at the same time.

The application takes seven seconds to initialize. The application exposes the /health API endpoint on HTTP port 3000. Configure the longload deployment to use this endpoint, to ensure that the application is ready before serving client requests.

Open a new terminal window and run the ~/DO180/labs/reliability-review/curl_loop.sh script.

 [student@workstation ~]$ ~/DO180/labs/reliability-review/curl_loop.sh
 1 longload-5897c9558f-cx4gt: Ok
 2 longload-5897c9558f-cx4gt: Ok
 3 longload-5897c9558f-cx4gt: Ok
 4 longload-5897c9558f-cx4gt: Ok
 ...output omitted...

Leave the script running and do not interrupt it.

Scale up the application to three replicas.

 [student@workstation ~]$ oc scale deployment/longload --replicas 3
 deployment.apps/longload scaled

Watch the output of the curl_loop.sh script in the second terminal. Some requests fail because OpenShift sends requests to the new pods before the application is ready.

 ...output omitted...
 22 longload-5897c9558f-cx4gt: Ok
 23 longload-5897c9558f-cx4gt: Ok
 24 longload-5897c9558f-cx4gt: Ok
 25 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection refused
 26 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection refused
 27 longload-5897c9558f-cx4gt: Ok
 28 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection refused
 29 longload-5897c9558f-cx4gt: Ok
 30 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection refused
 31 longload-5897c9558f-tpssf: app is still starting
 32 longload-5897c9558f-kkvm5: app is still starting
 33 longload-5897c9558f-cx4gt: Ok
 34 longload-5897c9558f-tpssf: app is still starting
 35 longload-5897c9558f-tpssf: app is still starting
 36 longload-5897c9558f-tpssf: app is still starting
 37 longload-5897c9558f-cx4gt: Ok
 38 longload-5897c9558f-tpssf: app is still starting
 39 longload-5897c9558f-cx4gt: Ok
 40 longload-5897c9558f-cx4gt: Ok
 ...output omitted...

Leave the script running and do not interrupt it.

Add a readiness probe to the longload deployment. Ignore the warning message.

 [student@workstation ~]$ oc set probe deployment/longload --readiness \
   --initial-delay-seconds 7 \
   --get-url http://:3000/health
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/longload probes updated

Scale down the application back to one pod.

 [student@workstation ~]$ oc scale deployment/longload --replicas 1
 deployment.apps/longload scaled

To test your work, scale up the application to three replicas again.

 [student@workstation ~]$ oc scale deployment/longload --replicas 3
 deployment.apps/longload scaled

Watch the output of the curl_loop.sh script in the second terminal. No request fails.

 ...output omitted...
 92 longload-7ddcc9b7fd-72dtm: Ok
 93 longload-7ddcc9b7fd-72dtm: Ok
 94 longload-7ddcc9b7fd-72dtm: Ok
 95 longload-7ddcc9b7fd-qln95: Ok
 96 longload-7ddcc9b7fd-wrxrb: Ok
 97 longload-7ddcc9b7fd-qln95: Ok
 98 longload-7ddcc9b7fd-wrxrb: Ok
 99 longload-7ddcc9b7fd-72dtm: Ok
 ...output omitted...

Press Ctrl+C to quit the script.

Hide Solution

Configure the application so that it automatically scales up when the average memory usage is above 60% of the memory requests value, and scales down when the usage is below this percentage. The minimum number of replicas must be one, and the maximum must be three. The resource that you create for scaling the application must be named longload.

The lab command provides the ~/DO180/labs/reliability-review/hpa.yml resource file as an example. Use the oc explain command to learn the valid parameters for the hpa.spec.metrics.resource.target attribute. Because the file is incomplete, you must update it first if you choose to use it.

To test your work, use the ~/DO180/labs/reliability-review/allocate.sh script that the lab command prepared. This script sends an HTTP request to the application /leak API endpoint. Each request consumes an additional 480 MiB of memory. To free this memory, you can use the ~/DO180/labs/reliability-review/free.sh script.
1. Before you create the horizontal pod autoscaler resource, scale down the application to one pod.
```
 [student@workstation ~]$ oc scale deployment/longload --replicas 1
 deployment.apps/longload scaled
```
2. Edit the ~/DO180/labs/reliability-review/hpa.yml resource file. You can retrieve the parameters for the resource attribute by using the oc explain hpa.spec.metrics.resource and oc explain hpa.spec.metrics.resource.target commands.
```
 apiVersion: autoscaling/v2
 kind: HorizontalPodAutoscaler
 metadata:
   name: longload
   labels:
     app: longload
 spec:
   maxReplicas: 3
   minReplicas: 1
   scaleTargetRef:
     apiVersion: apps/v1
     kind: Deployment
     name: longload
   metrics:
   - type: Resource
     resource:
       name: memory
       target:
         type: Utilization
         averageUtilization: 60
```
3. Use the oc apply command to deploy the horizontal pod autoscaler.
```
 [student@workstation ~]$ oc apply -f ~/DO180/labs/reliability-review/hpa.yml
 horizontalpodautoscaler.autoscaling/longload created
```
4. In the second terminal, run the watch command to monitor the oc get hpa longload command. Wait for the longload horizontal pod autoscaler to report usage in the TARGETS column. The percentage on your system probably differs.
```
 [student@workstation ~]$ watch oc get hpa longload
 Every 2.0s: oc get hpa longload            workstation: Fri Mar 10 05:15:34 2023

 NAME       REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
 longload   Deployment/longload   13%/60%   1         3         1          75s
```
  Leave the command running and do not interrupt it.
5. To test your work, run the ~/DO180/labs/reliability-review/allocate.sh script in the first terminal for the application to allocate 480 MiB of memory.
```
 [student@workstation ~]$ ~/DO180/labs/reliability-review/allocate.sh
 longload-7ddcc9b7fd-72dtm: consuming memory!
```
6. In the second terminal, after two minutes, the oc get hpa longload command shows the memory increase. The horizontal pod autoscaler scales up the application to more than one replica. The percentage on your system probably differs.
```
 Every 2.0s: oc get hpa longload            workstation: Fri Mar 10 05:19:44 2023

 NAME       REFERENCE             TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
 longload   Deployment/longload   145%/60%   1         3         2          5m18s
```
  Press Ctrl+C to quit the watch command. Close that second terminal when done.

Hide Solution

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade reliability-review

Finish

[student@workstation ~]$ lab finish reliability-review

Guided Exercise: Application Autoscaling

Syarif — Wed, 12 Jul 2023 11:14:47 GMT

Configure an autoscaler for an application and then load test that application to observe scaling up.

Outcomes

You should be able to manually scale up a deployment, configure a horizontal pod autoscaler resource, and monitor the autoscaler.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the reliability-autoscaling project.

[student@workstation ~]$ lab start reliability-autoscaling

Procedure 6.5. Instructions

Log in to the OpenShift cluster as the developer user with the developer password. Use the reliability-autoscaling project.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the reliability-autoscaling project as the active project.

 [student@workstation ~]$ oc project reliability-autoscaling
 ...output omitted...

Create the loadtest deployment, service, and route. The deployment uses the registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0 container image that provides a web application. The web application exposes an API endpoint that creates a CPU-intensive task when queried.

Review the ~/DO180/labs/reliability-autoscaling/loadtest.yml resource file that the lab command prepared. The container specification does not include the resources section that you use to specify CPU requests and limits. You configure that section in another step. Do not change the file for now.

 apiVersion: v1
 kind: List
 metadata: {}
 items:
   - apiVersion: apps/v1
     kind: Deployment
 ...output omitted...
         spec:
           containers:
           - image: registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0
             name: loadtest
             readinessProbe:
               failureThreshold: 3
               httpGet:
                 path: /api/loadtest/v1/healthz
                 port: 8080
                 scheme: HTTP
               periodSeconds: 10
               successThreshold: 1
               timeoutSeconds: 1

   - apiVersion: v1
     kind: Service
 ...output omitted...

   - apiVersion: route.openshift.io/v1
     kind: Route
 ...output omitted...

Use the oc apply command to create the application. Ignore the warning message.

 [student@workstation ~]$ oc apply -f \
 ~/DO180/labs/reliability-autoscaling/loadtest.yml
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/loadtest created
 service/loadtest created
 route.route.openshift.io/loadtest created

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                       READY   STATUS    RESTARTS   AGE
 loadtest-65c55b7dc-r4s4s   1/1     Running   0          49s
```

Configure a horizontal pod autoscaler resource for the loadtest deployment. Set the minimum number of replicas to 2 and the maximum to 20. Set the average CPU usage to 50% of the CPU requests attribute.

The horizontal pod autoscaler does not work, because the loadtest deployment does not specify requests for CPU usage.

Use the oc autoscale command to create the horizontal pod autoscaler resource.

 [student@workstation ~]$ oc autoscale deployment/loadtest --min 2 --max 20 \
 --cpu-percent 50
 horizontalpodautoscaler.autoscaling/loadtest autoscaled

Retrieve the status of the loadtest horizontal pod autoscaler resource. The unknown value in the TARGETS column indicates that OpenShift cannot compute the current CPU usage of the loadtest deployment. The deployment must include the CPU requests attribute for OpenShift to be able to compute the CPU usage.
```
 [student@workstation ~]$ oc get hpa loadtest
 NAME      REFERENCE            TARGETS         MINPODS  MAXPODS   REPLICAS   AGE
 loadtest  Deployment/loadtest  /50%   2        20        2          74s
```

Get more details about the resource status. You might have to rerun the command several times. Wait three minutes for the command to report the warning message.

 [student@workstation ~]$ oc describe hpa loadtest
 Warning: autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavailable in v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
 Name:                                                  loadtest
 Namespace:                                             reliability-autoscaling
 ...output omitted...
 Conditions:
   Type           Status  Reason                   Message
   ----           ------  ------                   -------
   AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
   ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: failed to get cpu utilization: missing request for cpu
 Events:
   Type     ... Message
   ----     ... -------
 ...output omitted...
   Warning  ... failed to get cpu utilization: missing request for cpu
 ...output omitted...

Delete the horizontal pod autoscaler resource. You re-create the resource in another step, after you fix the loadtest deployment.
```
 [student@workstation ~]$ oc delete hpa loadtest
 horizontalpodautoscaler.autoscaling "loadtest" deleted
```

Delete the loadtest application.

 [student@workstation ~]$ oc delete all -l app=loadtest
 pod "loadtest-65c55b7dc-r4s4s" deleted
 pod "loadtest-65c55b7dc-mgqr6" deleted
 service "loadtest" deleted
 deployment.apps "loadtest" deleted
 replicaset.apps "loadtest-65c55b7dc" deleted
 route.route.openshift.io "loadtest" deleted

Add a CPU resource section to the ~/DO180/labs/reliability-autoscaling/loadtest.yml file. Redeploy the application from the file.

Edit the ~/DO180/labs/reliability-autoscaling/loadtest.yml file, and configure the CPU limits and requests for the loadtest deployment. The pods need 25 millicores to operate, and must not consume more that 100 millicores.

You can compare your work with the completed ~/DO180/solutions/reliability-autoscaling/loadtest.yml file that the lab command prepared.

 ...output omitted...
         spec:
           containers:
           - image: registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0
             name: loadtest
             readinessProbe:
               failureThreshold: 3
               httpGet:
                 path: /api/loadtest/v1/healthz
                 port: 8080
                 scheme: HTTP
               periodSeconds: 10
               successThreshold: 1
               timeoutSeconds: 1
             resources:
               requests:
                 cpu: 25m
               limits:
                 cpu: 100m
 ...output omitted...

Use the oc apply command to deploy the application from the file. Ignore the warning message.

 [student@workstation ~]$ oc apply -f \
 ~/DO180/labs/reliability-autoscaling/loadtest.yml
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/loadtest created
 service/loadtest created
 route.route.openshift.io/loadtest created

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 loadtest-667bdcdc99-vhc9x   1/1     Running   0          36s
```

Manually scale the loadtest deployment by first increasing and then decreasing the number of running pods.

Scale up the loadtest deployment to five pods.

 [student@workstation ~]$ oc scale deployment/loadtest --replicas 5
 deployment.apps/loadtest scaled

Confirm that all five application pods are running. You might have to rerun the command several times for all the pods to report a Running status. The name of the pods on your system probably differ.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 loadtest-667bdcdc99-5fcvh   1/1     Running   0          43s
 loadtest-667bdcdc99-dpspr   1/1     Running   0          42s
 loadtest-667bdcdc99-hkssk   1/1     Running   0          43s
 loadtest-667bdcdc99-vhc9x   1/1     Running   0          8m11s
 loadtest-667bdcdc99-z5n9q   1/1     Running   0          43s

Scale down the loadtest deployment back to one pod.

 [student@workstation ~]$ oc scale deployment/loadtest --replicas 1
 deployment.apps/loadtest scaled

Confirm that only one application pod is running. You might have to rerun the command several times for the pods to terminate.

 [student@workstation ~]$ oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 loadtest-667bdcdc99-vhc9x   1/1     Running   0          11m

Configure a horizontal pod autoscaler resource for the loadtest deployment. Set the minimum number of replicas to 2 and the maximum to 20. Set the average CPU usage to 50% of the CPU request attribute.
1. Use the oc autoscale command to create the horizontal pod autoscaler resource.
```
 [student@workstation ~]$ oc autoscale deployment/loadtest --min 2 --max 20 \
 --cpu-percent 50
 horizontalpodautoscaler.autoscaling/loadtest autoscaled
```
2. Open a new terminal window and run the watch command to monitor the oc get hpa loadtest command. Wait five minutes for the loadtest horizontal pod autoscaler to report usage in the TARGETS column.
  
  Notice that the horizontal pod autoscaler scales up the deployment to two replicas, to conform with the minimum number of pods that you configured.
```
 [student@workstation ~]$ watch oc get hpa loadtest
 Every 2.0s: oc get hpa loadtest            workstation: Fri Mar  3 06:26:24 2023

 NAME       REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
 loadtest   Deployment/loadtest   0%/50%    2         20        2          52s
```
  Leave the command running, and do not interrupt it.
Increase the CPU usage by sending requests to the loadtest application API.
1. Use the oc get route command to retrieve the URL of the application.
```
 [student@workstation ~]$ oc get route loadtest
 NAME       HOST/PORT                                                ...
 loadtest   loadtest-reliability-autoscaling.apps.ocp4.example.com   ...
```
2. Send a request to the application API to simulate additional CPU pressure on the container. Do not wait for the curl command to complete, and continue with the exercise. After a minute, the command reports a timeout error that you can ignore.
```
 [student@workstation ~]$ curl \
 loadtest-reliability-autoscaling.apps.ocp4.example.com/api/loadtest/v1/cpu/1
 504 Gateway Time-out
 The server didn't respond in time.
 
```
3. Watch the output of the oc get hpa loadtest command in the second terminal. After a minute, the horizontal pod autoscaler detects an increase in the CPU usage and deploys additional pods.
  
  NOTE
  
  The increased activity of the application does not immediately trigger the autoscaler. Wait a few moments if you do not see any changes to the number of replicas.
  
  You might need to run the curl command multiple times before the application uses enough CPU to trigger the autoscaler.
  
  The CPU usage and the number of replicas on your system probably differ.
```
 Every 2.0s: oc get hpa loadtest            workstation: Fri Mar  3 07:20:19 2023

 NAME      REFERENCE             TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
 loadtest  Deployment/loadtest   220%/50%   2         20        9          16m
```
4. Wait five minutes after the curl command completes. The oc get hpa loadtest command shows that the CPU load decreases.
  
  NOTE
  
  Although the horizontal pod autoscaler resource can be quick to scale up, it is slower to scale down.
```
 Every 2.0s: oc get hpa loadtest            workstation: Fri Mar  3 07:23:11 2023

 NAME      REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
 loadtest  Deployment/loadtest   0%/50%    2         20        9          18m
```
5. Optional: Wait for the loadtest application to scale down. It takes five additional minutes for the horizontal pod autoscaler to scale down to two replicas.
```
 Every 2.0s: oc get hpa loadtest            workstation: Fri Mar  3 07:29:12 2023

 NAME      REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
 loadtest  Deployment/loadtest   0%/50%    2         20        2          24m
```
6. Press Ctrl+C to quit the watch command. Close that second terminal when done.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish reliability-autoscaling

Guided Exercise: Limit Compute Capacity for Applications

Syarif — Wed, 12 Jul 2023 11:10:59 GMT

Configure an application with compute resource limits that allow and prevent successful execution of its pods.

Outcomes

You should be able to monitor the memory usage of an application, and set a memory limit for a pod.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that all resources are available for this exercise. It also creates the reliability-limits project and the /home/student/DO180/labs/reliability-limits/resources.txt file. The resources.txt file contains some commands that you use during the exercise. You can use the file to copy and paste these commands.

[student@workstation ~]$ lab start reliability-limits

Procedure 6.4. Instructions

Log in to the OpenShift cluster as the developer user with the developer password. Use the reliability-limits project.

 [student@workstation ~]$ oc login -u developer -p developer \
   https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Set the reliability-limits project as the active project.

 [student@workstation ~]$ oc project reliability-limits
 ...output omitted...

Create the leakapp deployment from the ~/DO180/labs/reliability-limits/leakapp.yml file that the lab command prepared. The application has a bug, and leaks 1 MiB of memory every second.
1. Review the ~/DO180/labs/reliability-limits/leakapp.yml resource file. The memory limit is set to 35 MiB. Do not change the file.
```
 ...output omitted...
         resources:
           requests:
             memory: 20Mi
           limits:
             memory: 35Mi
```
2. Use the oc apply command to create the application. Ignore the warning message.
```
 [student@workstation ~]$ oc apply -f \
   ~/DO180/labs/reliability-limits/leakapp.yml
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/leakapp created
```
3. Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                      READY   STATUS    RESTARTS   AGE
 leakapp-99bb64c8d-hk26k   1/1     Running   0          12s
```

Watch the pod. OpenShift restarts the pod after 30 seconds.

Use the watch command to monitor the oc get pods command. Wait for OpenShift to restart the pod, and then press Ctrl+C to quit the watch command.

 [student@workstation ~]$ watch oc get pods
 Every 2.0s: oc get pods                    workstation: Wed Mar  8 07:27:45 2023

 NAME                      READY   STATUS    RESTARTS      AGE
 leakapp-99bb64c8d-hk26k   1/1     Running   1 (15s ago)   48s

Retrieve the container status to verify that OpenShift restarted the pod due to an Out-Of-Memory (OOM) event.

 [student@workstation ~]$ oc get pods leakapp-99bb64c8d-hk26k \
   -o jsonpath='{.status.containerStatuses[0].lastState}' | jq .
 {
   "terminated": {
     "containerID": "cri-o://5800...1d04",
     "exitCode": 137,
     "finishedAt": "2023-03-08T12:29:24Z",
     "reason": "OOMKilled",
     "startedAt": "2023-03-08T12:28:53Z"
   }
 }

Observe the pod status for a few minutes, until the CrashLoopBackOff status is displayed. During this period, OpenShift restarts the pod several times because of the memory leak.

Between each restart, OpenShift sets the pod status to CrashLoopBackOff, waits an increasing amount of time between retries, and then restarts the pod. The delay between restarts gives the operator the opportunity to fix the issue.

After various retries, OpenShift finally sets the CrashLoopBackOff wait timer to five minutes. During this wait time, the application is not available to your customers.
```
 [student@workstation ~]$ watch oc get pods
 Every 2.0s: oc get pods                    workstation: Wed Mar  8 07:33:15 2023

 NAME                      READY   STATUS             RESTARTS      AGE
 leakapp-99bb64c8d-hk26k   0/1     CrashLoopBackOff   4 (82s ago)   5m25s
```
Press Ctrl+C to quit the watch command.

Fixing the memory leak would resolve the issue. However, it might take some time for the developers to fix the bug. In the meantime, set the memory limit to 600 MiB. With this setting, the pod can run for ten minutes before the application reaches the limit.

Use the oc set resources command to set the new limit. Ignore the warning message.

 [student@workstation ~]$ oc set resources deployment/leakapp \
   --limits memory=600Mi
 Warning: would violate PodSecurity "restricted:v1.24":
 ...output omitted...
 deployment.apps/leakapp resource requirements updated

Wait for the pod to start. You might have to rerun the command several times for the pod to report a Running status. The name of the pod on your system probably differs.
```
 [student@workstation ~]$ oc get pods
 NAME                      READY   STATUS    RESTARTS   AGE
 leakapp-6bc64dfcd-86fpc   1/1     Running   0          12s
```

Wait two minutes to verify that OpenShift no longer restarts the pod every 30 seconds.

 [student@workstation ~]$ watch oc get pods
 Every 2.0s: oc get pods                    workstation: Wed Mar  8 07:38:15 2023

 NAME                      READY   STATUS    RESTARTS   AGE
 leakapp-6bc64dfcd-86fpc   1/1     Running   0          3m12s

Press Ctrl+C to quit the watch command.

Review the memory that the pod consumes. You might have to rerun the command several times for the metrics to be available. The memory usage on your system probably differs.
```
 [student@workstation ~]$ oc adm top pods
 NAME                      CPU(cores)   MEMORY(bytes)
 leakapp-6bc64dfcd-86fpc   0m           174Mi
```
Optional. Wait seven more minutes. After this period, OpenShift restarts the pod, because it reached the 600 MiB memory limit.
1. Open a new terminal window, and then run the watch command to monitor the oc adm top pods command.
```
 [student@workstation ~]$ watch oc adm top pods
 Every 2.0s: oc adm top pods                workstation: Wed Mar  8 07:38:55 2023

 NAME                      CPU(cores)   MEMORY(bytes)
 leakapp-6bc64dfcd-86fpc   0m           176Mi
```
  Leave the command running and do not interrupt it.
  
  NOTE
  
  You might see a message that metrics are not yet available. If so, wait some time and try again.
2. In the first terminal, run the watch command to monitor the oc get pods command. Watch the output of the oc adm top pods command in the second terminal. When the memory usage reaches 600 MiB, the OOM subsystem kills the process inside the container, and OpenShift restarts the pod.
```
 [student@workstation ~]$ watch oc get pods
 Every 2.0s: oc get pods                    workstation: Wed Mar  8 07:46:35 2023

 NAME                      READY   STATUS    RESTARTS     AGE
 leakapp-6bc64dfcd-86fpc   1/1     Running   1 (3s ago)   9m58s
```
  Press Ctrl+C to quit the watch command.
3. Press Ctrl+C to quit the watch command in the second terminal. Close this second terminal when done.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish reliability-limits

Guided Exercise: Reserve Compute Capacity for Applications

Syarif — Wed, 12 Jul 2023 11:08:57 GMT

Configure an application with compute resource requests that allow and prevent successful scheduling and scaling of its pods.

Outcomes

Observe that memory resource requests allocate cluster node memory.
Explore how adjusting resource requests impacts the number of replicas that can be scheduled on a node.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that the following conditions are true:

The reliability-requests project exists.
The resource files are available in the course directory.
The classroom registry has the registry.ocp4.example.com:8443/redhattraining/long-load:v1 container image.

The registry.ocp4.example.com:8443/redhattraining/long-load:v1 container image contains an application with utility endpoints. These endpoints perform such tasks as crashing the process and toggling the server's health status.

[student@workstation ~]$ lab start reliability-requests

Procedure 6.3. Instructions

As the admin user, deploy the long-load application by applying the long-load-deploy.yaml file in the reliability-requests project.
1. Log in as the admin user with the redhatocp password.
```
 [student@workstation ~]$ oc login https://api.ocp4.example.com:6443 -u admin
 ...output omitted...
```
  NOTE
  
  In general, use accounts with the least required privileges to perform a task. In the classroom environment, this account is the developer user. However, cluster administrator privileges are required to view the cluster node metrics in this exercise.
2. Select the reliability-requests project.
```
 [student@workstation ~]$ oc project reliability-requests
 Now using project "reliability-requests" on server "https://api.ocp4.example.com:6443".
```
3. Navigate to the ~/DO180/labs/reliability-requests directory. Create a deployment, service, and route by using the oc apply command and the long-load-deploy.yaml file.
```
 [student@workstation ~]$ cd DO180/labs/reliability-requests
 no output expected
```
```
 [student@workstation reliability-requests]$ oc apply -f long-load-deploy.yaml
 deployment.apps/long-load created
 service/long-load created
 route.route.openshift.io/long-load created
```
4. View the total memory request allocation for the node.
```
 [student@workstation reliability-requests]$ oc describe nodes
 ...output omitted...
 Allocated resources:
   (Total limits may be over 100 percent, i.e., overcommitted.)
   Resource           Requests       Limits
   --------           --------       ------
   cpu                3158m (42%)    980m (13%)
   memory             12667Mi (66%)  1250Mi (6%)
 ...output omitted...
```
  IMPORTANT
  
  Projects and objects from previous exercises can cause the memory usage from this exercise to mismatch the intended results. Delete any unrelated projects before continuing.
  
  If you still experience issues, re-create your classroom environment and try this exercise again.

Add a resource request to the pod definition and scale the deployment beyond the cluster's capacity.

Modify the long-load-deploy.yaml file by adding a resource request. The request allocates one gigabyte (1 G) to each of the application pods.

 spec:
   ...output omitted...
   template:
   ...output omitted...
     spec:
       containers:
       - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
         resources:
           requests:
             memory: 1G
 ...output omitted...

Apply the YAML file to modify the deployment with the resource request.

 [student@workstation reliability-requests]$ oc apply -f long-load-deploy.yaml
 deployment.apps/long-load configured
 service/long-load unchanged
 route.route.openshift.io/long-load configured

Scale the deployment to have 10 replicas.

 [student@workstation reliability-requests]$ oc scale deploy/long-load --replicas 10
 deployment.apps/long-load scaled

Observe that the cluster cannot schedule all of the pods on the single node. The pods with a Pending status cannot be scheduled.

 [student@workstation reliability-requests]$ oc get pods
 NAME                         READY   STATUS    RESTARTS   AGE
 ...output omitted...
 long-load-86bb4b79f8-44zwd   0/1     Pending   0          58s
 ...output omitted...

Retrieve the cluster event log, and observe that insufficient memory is the cause of the failed scheduling.

 [student@workstation reliability-requests]$ oc get events \
   --field-selector reason="FailedScheduling"
 ...output omitted... pod/long-load-86bb4b79f8-44zwd   0/1 nodes are available: 1 Insufficient memory. ...output omitted...

Alternatively, view the events for a pending pod to see the reason. In the following command, replace the pod name with one of the pending pods in your classroom.

 [student@workstation reliability-requests]$ oc describe \
   pod/long-load-86bb4b79f8-44zwd
 ...output omitted...
 Events:
 ...output omitted...  0/1 nodes are available: 1 Insufficient memory. ...output omitted...

Observe that the node's requested memory usage is high.

 [student@workstation reliability-requests]$ oc describe nodes
 ...output omitted...
 Allocated resources:
   (Total limits may be over 100 percent, i.e., overcommitted.)
   Resource           Requests          Limits
   --------           --------          ------
   cpu                3158m (42%)       980m (13%)
   memory             18830383Ki (97%)  1250Mi (6%)
 ...output omitted...

Reduce the requested memory per pod so that the replicas can run on the node.

Manually set the resource request to 250M.

 [student@workstation reliability-requests]$ oc set resources deploy/long-load \
   --requests memory=250M
 deployment.apps/long-load resource requirements updated

Delete the pods so that they are re-created with the new resource request.

 [student@workstation reliability-requests]$ oc delete pod -l app=long-load
 pod "long-load-557b4d94f5-29brx" deleted
 ...output omitted...

Observe that all of the pods can start with the lowered memory request. Within a minute, the pods are marked as Ready and in a Running state, with no pods in a Pending status.

 [student@workstation reliability-requests]$ oc get pods
 NAME                         READY   STATUS    RESTARTS   AGE
 long-load-557b4d94f5-68hbb   1/1     Running   0          3m14s
 long-load-557b4d94f5-bfk7c   1/1     Running   0          3m21s
 long-load-557b4d94f5-bnpzh   1/1     Running   0          3m21s
 long-load-557b4d94f5-chtv9   1/1     Running   0          3m21s
 long-load-557b4d94f5-drg2p   1/1     Running   0          3m14s
 long-load-557b4d94f5-hwsz6   1/1     Running   0          3m12s
 long-load-557b4d94f5-k5vqj   1/1     Running   0          3m21s
 long-load-557b4d94f5-lgstq   1/1     Running   0          3m21s
 long-load-557b4d94f5-r8hq4   1/1     Running   0          3m21s
 long-load-557b4d94f5-xrg7c   1/1     Running   0          3m21s

Observe that the memory usage of the node is lower.

 [student@workstation reliability-requests]$ oc describe nodes
 Allocated resources:
   (Total limits may be over 100 percent, i.e., overcommitted.)
   Resource           Requests           Limits
   --------           --------           ------
   cpu                3158m (42%)        980m (13%)
   memory             15782312192 (79%)  1250Mi (6%)
 ...output omitted...

Return to the /home/student/ directory.

 [student@workstation reliability-requests]$ cd /home/student/
 [student@workstation ~]$

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish reliability-requests

Guided Exercise: Application Health Probes

Syarif — Wed, 12 Jul 2023 11:08:12 GMT

Configure health probes in a deployment and verify that network clients are insulated from application failures.

Outcomes

Observe potential issues with an application that is not configured with health probes.
Configure startup, liveness, and readiness probes for the application.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that the following conditions are true:

The reliability-probes project exists.
The resource files are available in the course directory.
The classroom registry has the long-load container image.

[student@workstation ~]$ lab start reliability-probes

Procedure 6.2. Instructions

As the developer user, deploy the long-load application in the reliability-probes project.

 [student@workstation ~]$ oc login -u developer -p developer \
 https://api.ocp4.example.com:6443
 Login successful.
 ...output omitted...

Select the reliability-probes project.

 [student@workstation ~]$ oc project reliability-probes
 Now using project "reliability-probes" on server "https://api.ocp4.example.com:6443".

Navigate to the DO180/labs/reliability-probes directory and then apply the long-load-deploy.yaml file to create the pod. Move to the next step within one minute.

 [student@workstation ~]$ cd DO180/labs/reliability-probes

 [student@workstation reliability-probes]$ oc apply -f long-load-deploy.yaml
 deployment.apps/long-load created
 service/long-load created
 route.route.openshift.io/long-load created

Verify that the pods take several minutes to start by sending a request to a pod in the deployment.

 [student@workstation reliability-probes]$ oc exec deploy/long-load -- \
   curl -s localhost:3000/health
 app is still starting

Observe that the pods are listed as ready even though the application is not ready.

 [student@workstation reliability-probes]$ oc get pods
 NAME                         READY   STATUS    RESTARTS   AGE
 long-load-8564d998cc-579nx   1/1     Running   0          30s
 long-load-8564d998cc-ttqpg   1/1     Running   0          30s
 long-load-8564d998cc-wjtfw   1/1     Running   0          30s

Add a startup probe to the pods so that the cluster knows when the pods are ready.

Modify the long-load-deploy.yaml YAML file by defining a startup probe. The probe runs every three seconds and triggers a pod as failed after 30 failed attempts. The file should match the following excerpt:

 ...output omitted...
 spec:
   ...output omitted...
   template:
     ...output omitted...
     spec:
       containers:
       - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
         imagePullPolicy: Always
         name: long-load
         startupProbe:
           failureThreshold: 30
           periodSeconds: 3
           httpGet:
             path: /health
             port: 3000
         env:
 ...output omitted...

Scale down the deployment to zero replicas.

 [student@workstation reliability-probes]$ oc scale deploy/long-load --replicas 0
 deployment.apps/long-load scaled

Apply the updated long-load-deploy.yaml file. Because the YAML file specifies the number of replicas, the deployment is scaled up. Move to the next step within one minute.

 [student@workstation reliability-probes] oc apply -f long-load-deploy.yaml
 deployment.apps/long-load configured
 service/long-load unchanged
 route.route.openshift.io/long-load configured

Observe that the pods do not show as ready until the application is ready and the startup probe succeeds.

 [student@workstation reliability-probes]$ oc get pods
 NAME                         READY   STATUS    RESTARTS   AGE
 long-load-785b5b4fc8-7x5ln   0/1     Running   0          27s
 long-load-785b5b4fc8-f7pdk   0/1     Running   0          27s
 long-load-785b5b4fc8-r2nqj   0/1     Running   0          27s

Add a liveness probe so that broken instances of the application are restarted.

Start the load test script. The test begins to print Ok as the pods become available.

 [student@workstation reliability-probes]$ ./load-test.sh
 app is still starting
 app is still starting
 app is still starting
 ...output omitted...
 Ok
 Ok
 Ok
 ...output omitted...

Keep the script running in a visible window.

In a new terminal window, use the /togglesick endpoint to make one of the pods unhealthy.
```
 [student@workstation reliability-probes]$ oc exec \
   deploy/long-load -- curl -s localhost:3000/togglesick
 no output expected
```
The load test window begins to show app is unhealthy. Because only one pod is unhealthy, the remaining pods still respond with Ok.

Update the long-load-deploy.yaml file to add a liveness probe. The probe runs every three seconds and triggers the pod as failed after three failed attempts. Modify the spec.template.spec.containers object in the file to match the following excerpt.

 spec:
   ...output omitted...
   template:
     ...output omitted...
     spec:
       containers:
       - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
         ...output omitted...
         startupProbe:
           failureThreshold: 30
           periodSeconds: 3
           httpGet:
             path: /health
             port: 3000
         livenessProbe:
           failureThreshold: 3
           periodSeconds: 3
           httpGet:
             path: /health
             port: 3000
         env:
 ...output omitted...

Scale down the deployment to zero replicas.

 [student@workstation reliability-probes]$ oc scale deploy/long-load --replicas 0
 deployment.apps/long-load scaled

The load test script shows that the application is not available.

Apply the updated long-load-deploy.yaml file to update the deployment, which triggers the deployment to re-create its pods.

 [student@workstation reliability-probes]$ oc apply -f long-load-deploy.yaml
 deployment.apps/long-load configured
 service/long-load unchanged
 route.route.openshift.io/long-load configured

Wait for the load test window to show Ok for all responses, and then toggle one of the pods to be unhealthy.
```
 [student@workstation reliability-probes]$ oc exec \
   deploy/long-load -- curl -s localhost:3000/togglesick
 no output expected
```
The load test window might show app is unhealthy a number of times before the pod is restarted.

Observe that the unhealthy pod is restarted after the liveness probe fails. After the pod is restarted, the load test window shows only Ok.

 [student@workstation reliability-probes]$ oc get pods
 NAME                        READY   STATUS    RESTARTS       AGE
 long-load-fbb7468d9-8xm8j   1/1     Running   0              9m42s
 long-load-fbb7468d9-k66dm   1/1     Running   0              8m38s
 long-load-fbb7468d9-ncxkh   0/1     Running   1 (11s ago)    10m

Add a readiness probe so that traffic goes only to pods that are ready and healthy.
1. Scale down the deployment to zero replicas.
```
 [student@workstation reliability-probes]$ oc scale deploy/long-load --replicas 0
 deployment.apps/long-load scaled
```
2. Use the oc set probe command to add the readiness probe.
```
 [student@workstation reliability-probes]$ oc set probe deploy/long-load --readiness \
   --failure-threshold 1 --period-seconds 3 \
   --get-url http://:3000/health
 deployment.apps/long-load probes updated
```
3. Scale up the deployment to three replicas.
```
 [student@workstation reliability-probes]$ oc scale deploy/long-load --replicas 3
 deployment.apps/long-load scaled
```
4. Observe the status of the pods by using a watch command.
```
 [student@workstation reliability-probes]$ watch oc get pods
 NAME                        READY   STATUS    RESTARTS   AGE
 long-load-d5794d744-8hqlh   0/1     Running   0          48s
 long-load-d5794d744-hphgb   0/1     Running   0          48s
 long-load-d5794d744-lgkns   0/1     Running   0          48s
```
  The command does not immediately finish, but continues to show updates to the pods' status. Leave this command running in a visible window.
5. Wait for the pods to show as ready. Then, in a new terminal window, make one of the pods unhealthy for five seconds by using the /hiccup endpoint.
```
 [student@workstation reliability-probes]$ oc exec \
   deploy/long-load -- curl -s localhost:3000/hiccup?time=5
 no output expected
```
  The pod status window shows that one of the pods is no longer ready. After five seconds, the pod is healthy again and shows as ready.
  
  The load test window might show app is unhealthy one time before the pod is set as not ready. After the cluster determines that the pod is no longer ready, it stops sending traffic to the pod until either the pod is fixed or the liveness probe fails. Because the pod is sick only for five seconds, it is enough time for the readiness probe to fail, but not the liveness probe.
  
  NOTE
  
  Optionally, repeat this step and observe as the temporarily sick pod's status changes.
6. Stop the load test and status commands by pressing Ctrl+c in their respective windows. Return to the /home/student/ directory.
```
 [student@workstation reliability-probes]$ cd /home/student/
 [student@workstation ~]$
```

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish reliability-probes

Guided Exercise: Application High Availability with Kubernetes

Syarif — Wed, 12 Jul 2023 11:07:28 GMT

Simulate different types of application failures and observe how Kubernetes handles them.

Outcomes

Explore how the restartPolicy attribute affects crashing pods.
Observe the behavior of a slow-starting application that has no configured probes.
Use a deployment to scale the application, and observe the behavior of a broken pod.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that the following conditions are true:

The reliability-ha project exists.
The resource files are available in the course directory.
The classroom registry has the long-load container image.

The long-load container image contains an application with utility endpoints. These endpoints perform such tasks as crashing the process and toggling the server's health status.

[student@workstation ~]$ lab start reliability-ha

Procedure 6.1. Instructions

As the developer user, create a pod from a YAML manifest in the reliability-ha project.

 [student@workstation ~]$ oc login https://api.ocp4.example.com:6443 -u developer
 ...output omitted...

Select the reliability-ha project.

 [student@workstation ~]$ oc project reliability-ha
 Now using project "reliability-ha" on server "https://api.ocp4.example.com:6443".

Navigate to the lab materials directory and view the contents of the pod definition. In particular, restartPolicy is set to Always.

 [student@workstation ~]$ cd DO180/labs/reliability-ha

 [student@workstation reliability-ha]$ cat long-load.yaml
 apiVersion: v1
 kind: Pod
 metadata:
   name: long-load
 spec:
   containers:
   - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
     name: long-load
     securityContext:
       allowPrivilegeEscalation: false
   restartPolicy: Always

Create a pod by using the oc apply command.

 [student@workstation reliability-ha]$ oc apply -f long-load.yaml
 pod/long-load created

Send a request to the pod to confirm that it is running and responding.

 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/health
 Ok

Trigger the pod to crash, and observe that the restartPolicy instructs the cluster to re-create the pod.

Observe that the pod is running and has not restarted.

 [student@workstation reliability-ha]$ oc get pods

 NAME        READY   STATUS    RESTARTS   AGE
 long-load   1/1     Running   0          1m

Send a request to the /destruct endpoint in the application. This request triggers the process to crash.

 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/destruct
 command terminated with exit code 52

Observe that the pod is running and restarted one time.

 [student@workstation reliability-ha]$ oc get pods
 NAME        READY   STATUS    RESTARTS      AGE
 long-load   1/1     Running   1 (34s ago)   4m16s

Delete the long-load pod.
```
 [student@workstation reliability-ha]$ oc delete pod long-load
 pod "long-load" deleted
```
The pod is not re-created, because it was created manually, and not via a workload resource such as a deployment.

Use a restart policy of Never to create the pod, and observe that it is not re-created on crashing.

Modify the long-load.yaml file so that the restartPolicy is set to Never.
```
 ...output omitted...
   restartPolicy: Never
```

Create the pod with the updated YAML file.

 [student@workstation reliability-ha]$ oc apply -f long-load.yaml
 pod/long-load created

Send a request to the pod to confirm that the pod is running and that the application is responding.

 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/health
 Ok

Send a request to the /destruct endpoint in the application to crash it.

 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/destruct
 command terminated with exit code 52

Observe that the pod is not restarted and is in an error state.

 [student@workstation reliability-ha]$ oc get pods
 NAME        READY   STATUS   RESTARTS   AGE
 long-load   0/1     Error    0          2m36s

Delete the long-load pod.

 [student@workstation reliability-ha]$ oc delete pod long-load
 pod "long-load" deleted

Because the cluster does not know when the application inside the pod is ready to receive requests, you must add a startup delay to the application. Adding this capability by using probes is covered in a later exercise.
1. Update the long-load.yaml file by adding a startup delay and use a restart policy of Always. Set the START_DELAY variable to 60,000 milliseconds (one minute) so that the file looks like the following excerpt:
```
 ...output omitted...
 spec:
   containers:
   - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
     imagePullPolicy: Always
     securityContext:
       allowPrivilegeEscalation: false
     name: long-load
     env:
       - name: START_DELAY
         value: "60000"
   restartPolicy: Always
```
  NOTE
  
  Although numbers are a valid YAML type, environment variables must be passed as strings. YAML syntax is also indentation-sensitive.
  
  For these reasons, ensure that your file appears exactly as the preceding example.
2. Apply the YAML file to create the pod and proceed within one minute to the next step.
```
 [student@workstation reliability-ha]$ oc apply -f long-load.yaml
 pod/long-load created
```
3. Within a minute of pod creation, verify the status of the pod. The status shows as ready even though it is not. Try to send a request to the application, and observe that it fails.
```
 [student@workstation reliability-ha]$ oc get pods
 NAME        READY   STATUS    RESTARTS   AGE
 long-load   1/1     Running   0          16s
```
```
 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/health
 app is still starting
```
4. After waiting a minute for the application to start, send another a request to the pod to confirm that it is running and responding.
```
 [student@workstation reliability-ha]$ oc exec long-load -- \
   curl -s localhost:3000/health
 Ok
```
Use a deployment to scale up the number of deployed pods. Observe that deleting the pods causes service outages, even though the deployment handles re-creating the pods.
1. Review the long-load-deploy.yaml file, which defines a deployment, service, and route. The deployment creates three replicas of the application pod.
  
  In each pod, a START_DELAY environment variable is set to 15,000 milliseconds (15 seconds). In each pod, the application responds that it is not ready until after the delay.
```
 [student@workstation reliability-ha]$ cat long-load-deploy.yaml
 ...output omitted...
     spec:
       containers:
       - image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
         imagePullPolicy: Always
         name: long-load
         env:
         - name: START_DELAY
           value: "15000"
 ...output omitted...
```
2. Start the load test script, which sends a request to the /health API endpoint of the application every two seconds. Leave the script running in a visible terminal window.
```
 [student@workstation reliability-ha]$ ./load-test.sh
 ...output omitted...
```
3. In a new terminal window, apply the ~/DO180/labs/reliability-ha/long-load-deploy.yaml file.
```
 [student@workstation reliability-ha]$ oc apply -f \
   ~/DO180/labs/reliability-ha/long-load-deploy.yaml
 deployment.apps/long-load created
 service/long-load created
 route.route.openshift.io/long-load created
```
4. Watch the output of the load test script as the pods and the application instances start. After a delay, the requests succeed.
```
 ...output omitted...
 Ok
 Ok
 Ok
 ...output omitted...
```
5. By using the /togglesick API endpoint of the application, put one of the three pods into a broken state.
```
 [student@workstation reliability-ha]$ curl \
   long-load-reliability-ha.apps.ocp4.example.com/togglesick
 no output expected
```
6. Watch the output of the load test script as some requests start failing. Because of the load balancer, the exact order of the output is random.
```
 ...output omitted...
 Ok
 app is unhealthy
 app is unhealthy
 Ok
 Ok
 ...output omitted...
```
  Press Ctrl+C to end the load test script.
7. Return to the /home/student/ directory.
```
 [student@workstation reliability-ha]$ cd /home/student/
 [student@workstation ~]$
```

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish reliability-ha

Lab: Manage Storage for Application Configuration and Data

Syarif — Wed, 12 Jul 2023 11:06:18 GMT

Deploy a web application and its database that share database credentials from a secret. The database should use the default storage for the cluster. Also deploy a file-sharing application that runs with multiple replicas and shares its storage volume with a file uploader application. The file sharing and file uploader applications take configuration files from a config map and should use NFS file storage for shareability. The database should use local storage for increased and performance.

Outcomes

Deploy a database server.
Deploy a web application.
Create a secret that contains the database server credentials.
Create a configuration map that contains an SQL file.
Add and remove a volume on the database server and the web application.
Expose the database server and the web application.
Scale up the web application.
Mount the configuration map as a volume.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that the cluster is accessible and that all exercise resources are available. It also creates the storage-review project, and it creates files that this lab uses, in the /home/student/DO180/labs/storage-review directory.

[student@workstation ~]$ lab start storage-review

Procedure 5.5. Instructions

The API URL of your OpenShift cluster is https://api.ocp4.example.com:6443, and the oc command is already installed on your workstation machine.

Use the storage-review project for your work.

Log in to the OpenShift cluster and change to the storage-review project.

Show Solution
Create a secret named world-cred that contains the following data:

| Field | Value | | --- | --- | | User | redhat | | Password | redhat123 | | Database | world_x |

Show Solution
Create a configuration map named dbfiles by using the ~/DO180/labs/storage-review/insertdata.sql file.

Show Solution
Create a database server deployment named dbserver by using the registry.ocp4.example.com:8443/redhattraining/mysql-app:v1 container image. Then, set the missing environment variables by using the world-cred secret.

Show Solution
Add a volume to the dbserver deployment by using the following information:

| Field | Value | | --- | --- | | Name | dbserver-lvm | | Type | persistentVolumeClaim | | Claim mode | rwo | | Claim size | 1Gi | | Mount path | /var/lib/mysql | | Claim class | lvms-vg1 | | Claim name | dbserver-lvm-pvc |

Show Solution
Create a service for the dbserver deployment by using the following information:

| Field | Value | | --- | --- | | Name | mysql-service | | Port | 3306 | | Target port | 3306 |

Show Solution
Create a web application deployment named file-sharing by using the registry.ocp4.example.com:8443/redhattraining/php-webapp-mysql:v1 container image. Scale the deployment to two replicas. Then, expose the deployment by using the following information:

| Field | Value | | --- | --- | | Name | file-sharing | | Port | 8080 | | Target port | 8080 |

Create a route named file-sharing to expose the file-sharing web application to external access. Access the file-sharing route in a web browser to test the connection between the web application and the database server.

Show Solution
Mount the dbfiles configuration map to the file-sharing deployment as a volume named config-map-pvc. Set the mount path to the /home/database-files directory. Then, verify the content of the insertdata.sql file.

Show Solution
Add a shared volume to the file-sharing deployment. Use the following information to create the volume:

| Field | Value | | --- | --- | | Name | shared-volume | | Type | persistentVolumeClaim | | Claim mode | rwo | | Claim size | 1Gi | | Mount path | /home/sharedfiles | | Claim class | nfs-storage | | Claim name | shared-pvc |

Next, connect to a file-sharing deployment pod and then use the cp command to copy the /home/database-files/insertdata.sql file to the /home/sharedfiles directory. Then, remove the config-map-pvc volume from the file-sharing deployment.

Show Solution
Add the shared-volume PVC to the dbserver deployment. Then, connect to a dbserver deployment pod and verify the content of the /home/sharedfiles/insertdata.sql file.

Show Solution
Connect to the database server and execute the /home/sharedfiles/insertdata.sql file to add data to the world_x database. You can execute the file by using the following command:
```
mysql -u$MYSQL_USER -p$MYSQL_PASSWORD world_x 
```
Then, confirm connectivity between the web application and database server by accessing the file-sharing route in a web browser.


    Show Solution
Evaluation
As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.
[student@workstation ~]$ lab grade storage-review

Finish
As the student user on the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.
[student@workstation ~]$ lab finish storage-review

Untitled Publication

connect Amavis to an external ClamAV daemon using TCP

1. Update @av_scanners Configuration

Running the Traefik 3 Hardened Image (nonroot) on Podman: 3 Problems and Their Fixes

The starting setup

Problem 1: listen tcp :8080: bind: address already in use

Problem 2: permission denied when connecting to the Podman socket

Problem 3: The real fix — a Docker/Podman Socket Proxy

Why this approach is better

Summary

Why I Didn’t Trust Bitcoin at First — Until I Found a Way to Solve Its Biggest Problem

The Fear of Permanent Loss

How I Found a Better Way

"Not Your Keys, Not Your Coins"

Choosing an Exchange Wisely

Final Thoughts

How to Create a Free Email Account with a Custom Domain Name in Zoho.com

How to Manage Your Domain for Free Using Cloudflare

How to Buy a Domain Name from IDCloudHost.com

Lab: Troubleshoot and Scale Applications

Quote List

Lab: Deploy Web Applications

Quote List

Lab: Manage Application Updates

Guided Exercise: Automatic Image Updates with OpenShift Image Change Triggers

NOTE

Guided Exercise: Reproducible Deployments with OpenShift Image Streams

NOTE

Guided Exercise: Update Application Image and Settings

Guided Exercise: Container Image Identity and Tags

NOTE

NOTE

Lab: Configure Applications for Reliability

Guided Exercise: Application Autoscaling

504 Gateway Time-out

NOTE

NOTE

Guided Exercise: Limit Compute Capacity for Applications

NOTE

Guided Exercise: Reserve Compute Capacity for Applications

NOTE

IMPORTANT

Guided Exercise: Application Health Probes

NOTE

Guided Exercise: Application High Availability with Kubernetes

NOTE

Lab: Manage Storage for Application Configuration and Data

1. Update `@av_scanners` Configuration

Problem 1: `listen tcp :8080: bind: address already in use`

Problem 2: `permission denied` when connecting to the Podman socket