1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OSDOCS-9598: pre-pub 4.16 MicroShift nits

This commit is contained in:
“Shauna Diaz”
2024-05-29 12:43:34 -04:00
committed by openshift-cherrypick-robot
parent 9d9a25bef8
commit 4e21d31681
11 changed files with 29 additions and 70 deletions

View File

@@ -1,6 +1,6 @@
:_mod-docs-content-type: ASSEMBLY
[id="microshift-audit-logs-config"]
= Customizing audit logging policies
= Configuring audit logging policies
include::_attributes/attributes-microshift.adoc[]
:context: microshift-audit-logs-config

View File

@@ -22,6 +22,6 @@ include::modules/microshift-custom-ca-troubleshooting.adoc[leveloffset=+1]
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/creating-and-managing-tls-keys-and-certificates_securing-networks#doc-wrapper[RHEL: Creating and managing TLS keys and certificates]
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore] for details.
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore]
* link:https://docs.openshift.com/container-platform/{ocp-version}/cli_reference/openshift_cli/managing-cli-profiles.html[OpenShift CLI Reference: oc login]

View File

@@ -8,7 +8,7 @@ toc::[]
Greenboot is the generic health check framework for the `systemd` service on `rpm-ostree` systems such as {op-system-ostree-first}. This framework is included in {microshift-short} installations with the `microshift-greenboot` and `greenboot-default-health-checks` RPM packages.
Greenboot health checks run at various times to assess system health and automate a rollback to the last healthy state in the event of software trouble, for example:
Greenboot health checks run at various times to assess system health and automate a rollback on `rpm-ostree` systems to the last healthy state in cases of software trouble, for example:
* Default health check scripts run each time the system starts.
* In addition the to the default health checks, you can write, install, and configure application health check scripts to also run every time the system starts.
@@ -17,11 +17,6 @@ Greenboot health checks run at various times to assess system health and automat
A {microshift-short} application health check script is included in the `microshift-greenboot` RPM. The `greenboot-default-health-checks` RPM includes health check scripts verifying that DNS and `ostree` services are accessible. You can create your own health check scripts for the workloads you are running. You can write one that verifies that an application has started, for example.
[NOTE]
====
Rollback is not possible in the case of an update failure on a system not using `rpm-ostree`. This is true even though health checks might run.
====
include::modules/microshift-greenboot-dir-structure.adoc[leveloffset=+1]
include::modules/microshift-greenboot-microshift-health-script.adoc[leveloffset=+1]

View File

@@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
toc::[]
In addition to the default OVN-Kubernetes Container Network Interface (CNI) plugin, {microshift-short} uses an implementation of the Multus CNI to chain other CNI plugins.
In addition to the default OVN-Kubernetes Container Network Interface (CNI) plugin, the {microshift-short} Multus CNI is available to chain other CNI plugins. Installing and using {microshift-short} Multus is optional.
include::modules/microshift-multus-intro.adoc[leveloffset=+1]

View File

@@ -30,21 +30,21 @@ include::modules/microshift-gitops-adding-apps.adoc[leveloffset=+1]
GitOps with Argo CD for {microshift-short} has the following differences from the Red Hat OpenShift GitOps Operator:
* The `gitops-operator` component is not used with {microshift-short}.
* To maintain the small resource use of {microshift-short}, the Argo CD web console is not available. You can use the Argo CD CLI or use a pull-based approach.
* To maintain the small resource use of {microshift-short}, the Argo CD web console is not available. You can use the Argo CD CLI.
* Because {microshift-short} is single-node, there is no multi-cluster support. Each instance of {microshift-short} is paired with a local GitOps agent.
* The `oc adm must-gather` command is not available in {microshift-short}.
[id="microshift-gitops-troubleshooting_{context}"]
== Troubleshooting GitOps
If you have problems with your GitOps controller, you can use either the {oc-first} tool or run an sos report.
If you have problems with your GitOps controller, you can use the {oc-first} tool.
include::modules/microshift-gitops-debug.adoc[leveloffset=+2]
include::modules/microshift-gathering-sos-report.adoc[leveloffset=+2]
[id="additional-resources_microshift-gitops_{context}"]
[role="_additional-resources"]
== Additional resources
* xref:../microshift_install/microshift-install-rpm.adoc#microshift-installing-rpms-for-gitops_microshift-install-rpm[Installing the GitOps Argo CD manifests from an RPM package]
* xref:../microshift_support/microshift-sos-report.adoc#microshift-sos-report[Using sos reports]
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_gitops/1.12[Red Hat OpenShift GitOps]

View File

@@ -21,7 +21,7 @@ Data backups are automatic on `rpm-ostree` systems. If you are not using an `rpm
[id="troubleshoot-backup-restore-microshift-backup-logs_{context}"]
== Backup logs
* Logs print to the console during manual backups.
* Logs print to the terminal console during manual backups.
* Logs are automatically generated for `rpm-ostree` system automated backups as part of the {microshift-short} journal logs. You can check the logs by running the following command:
+
[source,terminal]

View File

@@ -41,5 +41,5 @@ If any validation fails, the {microshift-short} service skips the custom configu
[IMPORTANT]
====
Custom server certificates have to be validated against CA data configured in the trust root of the host operating system.
Custom server certificates have to be validated against CA data configured in the trust root of the host operating system. For information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore].
====

View File

@@ -8,51 +8,15 @@
You can create a custom YAML configuration to deploy and manage applications in your {microshift-short} service. To install the necessary packages to run GitOps applications, follow the documentation in "Installing the GitOps Argo CD manifests from an RPM package".
.Prerequisites
.Prerequisites
* You installed the `microshift-gitops` packages and the Argo CD pods are running in the `openshift-gitops` namespace.
* You installed the `microshift-gitops` packages.
.Procedure
* The Argo CD pods are running in the `openshift-gitops` namespace.
. Create a YAML file and add your customized configurations for the application:
+
.Example YAML for a `cert-manager` application
[source,yaml]
----
kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
name: default
namespace: openshift-gitops
spec:
clusterResourceWhitelist:
- group: '*'
kind: '*'
destinations:
- namespace: '*'
server: '*'
sourceRepos:
- '*'
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: cert-manager
namespace: openshift-gitops
spec:
destination:
namespace: cert-manager
server: https://kubernetes.default.svc
project: default
source:
path: cert-manager
repoURL: https://github.com/anandf/microshift-install
syncPolicy:
automated: {}
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
----
.Procedure
. Create a YAML file and add your customized configurations for the application:
+
.Example YAML for a `spring-petclinic` application
[source,yaml]
@@ -98,10 +62,11 @@ spec:
+
[source,terminal]
----
$ oc apply -f <filename>.yaml
$ oc apply -f <my-app>.yaml <1>
----
<1> Replace _<my-app>_ with the name of your application YAML.
.Verification
.Verification
* To verify your application is deployed and synced, run the following command:
+
@@ -111,10 +76,9 @@ $ oc get applications -A
----
It might take a few minutes for the application to show the `Healthy` status.
+
.Example output
.Example output
[source,terminal]
----
NAMESPACE NAME SYNC STATUS HEALTH STATUS
openshift-gitops cert-manager Synced Healthy
openshift-gitops spring-petclinic Synced Healthy
----

View File

@@ -28,7 +28,7 @@ Setting network policies for additional networks is not supported.
[id="microshift-additional-network-use-cases_{context}"]
== Use case: Additional networks for network isolation
You can use an additional network in situations where network isolation is needed, including control plane and data plane separation. You can create additional interfaces for pods to connect to that network in addition to a default. For example, you can configure an additional interface if you want pods to access a network on the host and also communicate with devices deployed to the edge. These edge devices might be on an isolated operator network or are periodically disconnected.
You can use an additional network in situations where network isolation is needed, including control plane and data plane separation. For example, you can configure an additional interface if you want pods to access a network on the host and also communicate with devices deployed to the edge. These edge devices might be on an isolated operator network or are periodically disconnected.
Isolating network traffic is useful for the following performance and security reasons:

View File

@@ -28,7 +28,7 @@ apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] <1>
k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] # <1>
# ...
----
<1> Replace `<network>` with the name of the additional network to associate with the pod. To specify more than one additional network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same additional network multiple times, that pod will have multiple network interfaces attached to that network.
@@ -56,9 +56,9 @@ metadata:
k8s.v1.cni.cncf.io/networks: |-
[
{
"name": "<network>", <1>
"namespace": "<namespace>", <2>
"default-route": ["<default-route>"] <3>
"name": "<network>", # <1>
"namespace": "<namespace>", # <2>
"default-route": ["<default-route>"] # <3>
}
]
# ...
@@ -151,7 +151,7 @@ kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: bridge-conf
k8s.v1.cni.cncf.io/network-status: |- <1>
k8s.v1.cni.cncf.io/network-status: |- # <1>
[{
"name": "ovn-kubernetes",
"interface": "eth0",

View File

@@ -39,7 +39,7 @@ storageConfig:
imageURL: registry.example.com/oc-mirror
skipTLS: false
mirror:
platform: <1>
platform: # <1>
channels:
- name: stable-4.15
type: ocp
@@ -49,9 +49,9 @@ mirror:
- name: serverless-operator
channels:
- name: stable
additionalImages: <2>
additionalImages: # <2>
- name: registry.redhat.io/ubi8/ubi:latest
helm: {} <3>
helm: {} # <3>
----
<1> The `platform` field and related fields are not supported by {microshift-short} and must be deleted.
<2> Specify any additional images to include in the image set. If you do not need to specify additional images, delete this field.