bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update Docker & Kubernetes/Servers/AWX/AWX Operator/AWX Operator Deployment.md

Browse Source
This commit is contained in:
Nicole Rappe
2024-09-26 04:21:14 -06:00
parent 7d2447de5a
commit f064d5e98d
1 changed files with 9 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
Docker & Kubernetes/Servers/AWX/AWX Operator/AWX Operator Deployment.md
View File

@ -43,7 +43,7 @@ You will need to create these files all in the same directory using the content
=== "awx.yml" === "awx.yml"
```jsx title="/awx/awx.yml" ```yaml title="/awx/awx.yml"
apiVersion: awx.ansible.com/v1beta1 apiVersion: awx.ansible.com/v1beta1
kind: AWX kind: AWX
metadata: metadata:
@ -54,7 +54,7 @@ You will need to create these files all in the same directory using the content
=== "ingress.yml" === "ingress.yml"
```jsx title="/awx/ingress.yml" ```yaml title="/awx/ingress.yml"
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
kind: Ingress kind: Ingress
metadata: metadata:
@ -75,7 +75,7 @@ You will need to create these files all in the same directory using the content
=== "kustomization.yml" === "kustomization.yml"
```jsx title="/awx/kustomization.yml" ```yaml title="/awx/kustomization.yml"
apiVersion: kustomize.config.k8s.io/v1beta1 apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization kind: Kustomization
resources: resources:
@ -243,9 +243,9 @@ At this point, we need to make an "Instance Group" for the AWX Execution Environ
Create the following files in the `/awx` folder on the AWX Operator server you deployed earlier when setting up the Kubernetes Cluster and deploying AWX Operator into it so we can later mount them into the new Execution Environment we will be building. Create the following files in the `/awx` folder on the AWX Operator server you deployed earlier when setting up the Kubernetes Cluster and deploying AWX Operator into it so we can later mount them into the new Execution Environment we will be building.
=== "/awx/custom_dns_records.yml" === "Custom DNS Records"
``` yaml ```yaml title="/awx/custom_dns_records.yml"
apiVersion: v1 apiVersion: v1
kind: ConfigMap kind: ConfigMap
metadata: metadata:
@ -259,9 +259,9 @@ Create the following files in the `/awx` folder on the AWX Operator server you d
192.168.3.5 BUNNY-NODE-02.bunny-lab.io BUNNY-NODE-02 192.168.3.5 BUNNY-NODE-02.bunny-lab.io BUNNY-NODE-02
``` ```
=== "/awx/krb5.conf" === "Kerberos Keytab File"
``` ```yaml title="/awx/krb5.conf"
[libdefaults] [libdefaults]
default_realm = BUNNY-LAB.IO default_realm = BUNNY-LAB.IO
dns_lookup_realm = false dns_lookup_realm = false
@ -291,7 +291,7 @@ kubectl apply -f custom_dns_records.yml
- Open AWX UI and click on "**Instance Groups**" under the "**Administration**" section, then press "**Add > Add container group**". - Open AWX UI and click on "**Instance Groups**" under the "**Administration**" section, then press "**Add > Add container group**".
- Enter a descriptive name as you like (e.g. `Kerberos`) and click the toggle "**Customize Pod Specification**". - Enter a descriptive name as you like (e.g. `Kerberos`) and click the toggle "**Customize Pod Specification**".
- Put the following YAML string in "**Custom pod spec**" then press the "**Save**" button - Put the following YAML string in "**Custom pod spec**" then press the "**Save**" button
``` yaml ```yaml title="Custom Pod Spec"
apiVersion: v1 apiVersion: v1
kind: Pod kind: Pod
metadata: metadata:
@ -361,18 +361,3 @@ ansible_winrm_server_cert_validation=ignore
It is **critical** that you define Kerberos-authenticated devices with fully qualified domain names. This is just something I found out from 4+ hours of troubleshooting. If the device is Linux or you are using NTLM authentication instead of Kerberos authentication, you can skip this warning. If you do not define the inventory using FQDNs, it will fail to run the commands against the targeted device(s). It is **critical** that you define Kerberos-authenticated devices with fully qualified domain names. This is just something I found out from 4+ hours of troubleshooting. If the device is Linux or you are using NTLM authentication instead of Kerberos authentication, you can skip this warning. If you do not define the inventory using FQDNs, it will fail to run the commands against the targeted device(s).
In this example, the host is defined via FQDN: `virt-node-01 ansible_host=virt-node-01.bunny-lab.io` In this example, the host is defined via FQDN: `virt-node-01 ansible_host=virt-node-01.bunny-lab.io`
Lastly, we want to ensure we have Keytab generation happening when the playbook is executed, so add these tasks to the beginning of your playbook(s) that interact with Kerberos devices:
``` yaml
- name: Acquire Kerberos Ticket using Keytab
ansible.builtin.shell: |
kinit -kt /etc/krb5.keytab {{ kerberos_user }}
environment:
KRB5_CONFIG: /etc/krb5.conf
register: kinit_result
- name: Ensure Kerberos Ticket was Acquired Successfully
fail:
msg: "Failed to acquire Kerberos ticket"
when: kinit_result.rc != 0
```