### Ansible Galaxy Install Command - Shell

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This shell command illustrates the equivalent manual execution of installing Ansible requirements from a `requirements.yml` file, which is what the provider generates internally.

```shell
ansible-galaxy install -r requirements.yml
```

--------------------------------

### Install Ansible Role from Ansible Galaxy using Shell Command

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This shell command illustrates how to install an Ansible role from Ansible Galaxy using the `ansible-galaxy` command-line tool. This is the default behavior when referencing roles in the `AnsibleRun` resource without specifying an alternative source. It fetches community-maintained roles.

```shell
ansible-galaxy role install sample_namespace.sample_role
```

--------------------------------

### ObserveAndDelete Policy Example for AnsibleRun

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example demonstrates how to use the ObserveAndDelete policy to provision an OpenShift cluster remotely using an Ansible role. It defines the desired state in spec.forProvider.vars and uses an annotation to specify the policy. The policy dictates that Observe() is called when the resource is present and Delete() when it's absent, both invoking the same Ansible content.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: openshift-cluster
  annotations:
    ansible.crossplane.io/runPolicy: ObserveAndDelete
spec:
  forProvider:
    roles:
    - sample_namespace.openshift_cluster
    vars:
      ocpVersion: "4.8.27"
      platform: "x"
      size: "large"
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### CheckWhenObserve Policy Example for AnsibleRun

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example illustrates the use of the CheckWhenObserve policy for running Ansible roles. When this policy is applied, the provider executes Ansible in check mode during Observe() calls. If changes are detected, it triggers an Update() operation; otherwise, Delete() is handled as usual upon resource deletion. This policy is suitable for Ansible modules that support check mode.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
  annotations:
    ansible.crossplane.io/runPolicy: CheckWhenObserve
spec:
  forProvider:
    roles:
    - sample_namespace.sample_role
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Configure Ansible Paths via ProviderConfig (YAML)

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

Example of using a ProviderConfig resource to set environment variables that customize Ansible's behavior, such as specifying the paths for roles and collections. This provides a global configuration for Ansible runs.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  vars:
    # Specify the path where the Ansible roles are located
    - key: ANSIBLE_ROLE_PATH 
      value: /path/to/roles
    # Specify the path where the Ansible collections are located
    - key: ANSIBLE_COLLECTION_PATH 
      value: /path/to/collections
```

--------------------------------

### Run Inline Ansible Playbook with Kubernetes Resource

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example demonstrates how to define an `AnsibleRun` Kubernetes resource to execute an inline Ansible playbook. The playbook is directly embedded within the resource definition and uses the `debug` module to display a message. This is primarily useful for quick testing and simple scenarios.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: inline-example
spec:
  forProvider:
    # For simple cases, you can use an inline source to specify the content of
    # playbook.yml as opaque and inline yaml.
    playbookInline: |
      ---
      - hosts: localhost
        tasks:
          - name: simple-playbook
            debug:
              msg: You are running 'simple-playbook'
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Sequentially Run Multiple Ansible Playbooks using AnsibleRun

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example shows how to run multiple Ansible playbooks sequentially using the `spec.forProvider.playbooks` field in an `AnsibleRun` resource. Each playbook in the list will be executed one after another. Note that at the time of writing, only single playbook execution is officially supported, implying this feature might be experimental or have limitations.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
spec:
  forProvider:
    playbooks:
      - sample_namespace.sample_collection.sample_playbook
      - sample_namespace.sample_collection.another_sample_playbook
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Declare Ansible Collection from Private GitHub with Credentials - YAML

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example illustrates how to configure the Ansible provider to fetch collections from a private GitHub repository. It requires defining `credentials` in the `ProviderConfig` and referencing a Kubernetes secret containing the necessary Git credentials.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  credentials:
    - filename: .git-credentials
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: git-credentials
        key: .git-credentials
  requirements: |
    ---
    collections:
      # Install a collection from GitHub repository.
      - name: https://github.com/sample_namespace/sample_collection.git
        version: 0.1.0
        type: git
```

--------------------------------

### Declare Ansible Collection from GitHub Repository - YAML

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This YAML configuration shows how to specify an Ansible collection to be installed directly from a GitHub repository. It includes the repository URL and the desired version.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  requirements: |
    ---
    collections:
      # Install a collection from GitHub repository.
      - name: https://github.com/sample_namespace/sample_collection.git
        version: 0.1.0
        type: git
```

--------------------------------

### Define AnsibleRun Variables (YAML)

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

Example of defining simple, list, and dictionary variables within an AnsibleRun resource. These variables are passed to the specified Ansible role for consumption.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
spec:
  forProvider:
    roles:
    - sample_namespace.sample_role
    vars:
      foo: value1
      bar:
      - value2
      - value3
      baz:
        field 1: value1
        field 2: value2
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Run Multiple Remote Ansible Roles Sequentially with Kubernetes Resource

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This example shows how to configure an `AnsibleRun` Kubernetes resource to execute multiple Ansible roles hosted remotely. The roles are listed in the `spec.forProvider.roles` field and will be executed sequentially. By default, these roles are fetched from Ansible Galaxy.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
spec:
  forProvider:
    roles:
      - sample_namespace.sample_role
      - sample_namespace.another_sample_role
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### AnsibleRun with Remote Roles

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

References Ansible roles from remote sources like GitHub repositories. This, combined with run policies and variables, facilitates complex infrastructure provisioning. The example uses the CheckWhenObserve run policy.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  annotations:
    # CheckWhenObserve: runs in check mode during Observe, then applies changes in Update
    ansible.crossplane.io/runPolicy: CheckWhenObserve
  name: gcpdisk
spec:
  forProvider:
    # Remote roles fetched from GitHub repository
    roles:
      - name: ansible_provider.gcpdisk_role
        src: https://github.com/multicloudlab/crossplane-ansible-provider-sample.git
    # Variables passed to the Ansible role - supports nested structures
    vars:
      project:
        disk:
          size: 20
          key: 718BDCC469891
          zone: europe-west1-b
        id: test_project
  providerConfigRef:
    name: gcpconfig
```

--------------------------------

### Declare Ansible Collection from Ansible Galaxy - YAML

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This snippet demonstrates how to declare an Ansible collection to be installed from Ansible Galaxy using the `requirements` field in a `ProviderConfig` resource. It specifies the collection name and version.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  requirements: |
    ---
    collections:
      # Install a collection from Ansible Galaxy.
      - name: sample_namespace.sample_collection
        version: 0.1.0
        source: https://galaxy.ansible.com
```

--------------------------------

### AnsibleRun with Secret-Based Inventory

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Retrieves inventory configuration from Kubernetes Secrets, allowing sensitive or dynamically managed host lists to be stored securely and referenced by the AnsibleRun resource. The example first creates a Secret with base64-encoded inventory data.

```yaml
# First, create a Secret containing the inventory
apiVersion: v1
kind: Secret
metadata:
  namespace: crossplane-system
  name: inventory
type: Opaque
data:
  # Base64-encoded inventory content
  hosts: QkFTRTY0RU5DT0RFRF9IT1NUUw==
---
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: secret-inventory-remote-debug
spec:
  forProvider:
    # Reference inventory from Kubernetes Secret
    inventories:
      - source: Secret
        secretRef:
          namespace: crossplane-system
          name: inventory
          key: hosts
    playbookInline: |
      ---
      - hosts: all
        tasks:
          - name: ansibleplaybook-simple
            debug:
              msg: Your are running 'ansibleplaybook-simple' example
```

--------------------------------

### Conditional Ansible Playbook Execution based on Resource State

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This snippet shows how to conditionally execute Ansible tasks within a playbook based on the state of the managed resource. The `ansible_provider_meta.managed_resource.state` variable, provided by the Ansible provider, indicates whether the `AnsibleRun` resource is present or absent, allowing for distinct setup and cleanup logic.

```yaml
- include_tasks: setup-resource.yml
  when: ansible_provider_meta.managed_resource.state == 'present'

- include_tasks: cleanup-resource.yml
  when: ansible_provider_meta.managed_resource.state == 'absent'
```

--------------------------------

### AnsibleRun with Executable Inventory

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Demonstrates how to use dynamic inventory scripts with AnsibleRun by enabling executable inventory mode. This allows Python or shell scripts to generate inventory dynamically. The `inventoryInline` field accepts a script that outputs JSON inventory.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: executable-inventory
spec:
  forProvider:
    # Enable executable inventory for dynamic host discovery
    executableInventory: True
    # Python script that generates inventory dynamically
    inventoryInline: |
      #!/usr/bin/env python3
      import json
      import argparse
      if __name__ == "__main__":
        parser = argparse.ArgumentParser()
        parser.add_argument("--list", action="store_true", help="Show JSON of all managed hosts")
        parser.add_argument("--host", help="Display vars related to the host")
        args = parser.parse_args()
      if args.list:
          print(json.dumps({"all": {"hosts": ["localhost"]}}, indent=4))
      elif args.host:
        print(json.dumps({"ansible_connection": "local"}, indent=4))

    playbookInline: |
      ---
      - hosts: all
        tasks:
          - name: ansibleplaybook-simple
            debug:
              msg: Your are running 'ansibleplaybook-simple' example

```

--------------------------------

### Run Ansible Playbook from Collection using AnsibleRun

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This snippet demonstrates how to execute an Ansible playbook that is part of a collection. It uses the `spec.forProvider.playbook` field within an `AnsibleRun` resource. The collection containing the playbook must be defined as a requirement in the `ProviderConfig`.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
spec:
  forProvider:
    playbook: sample_namespace.sample_collection.sample_playbook
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Run Inline Ansible Playbook with Collection Role using AnsibleRun

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This snippet illustrates how to execute an inline Ansible playbook that includes a role from a collection. It utilizes the `spec.forProvider.playbookInline` field in an `AnsibleRun` resource. The necessary collection, such as `nginxinc.nginx_core`, must be specified in the `ProviderConfig` requirements.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: inline-example
spec:
  forProvider:
    playbookInline: |
      ---
      - hosts: all
        collections:
          - nginxinc.nginx_core
        tasks:
          - name: Install NGINX
            include_role:
              name: nginx
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### Reference Variables from ConfigMap/Secret (YAML)

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

Illustrates how to reference variables stored in a ConfigMap or Secret for an AnsibleRun resource. This feature, using `varFiles`, is planned for future releases and mimics Ansible's `vars_files` functionality.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: remote-example
spec:
  forProvider:
    roles:
    - sample_namespace.sample_role
    varFiles:
    - source: ConfigMapKey
      configMapKeyRef:
        namespace: default
        name: plain_vars
        key: plain_vars.yml
    - source: SecretKey
      secretKeyRef:
        namespace: default
        name: secret_vars
        key: secret_vars.yml
  providerConfigRef:
    name: provider-config-example
```

--------------------------------

### AnsibleRun with ObserveAndDelete Policy

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Utilizes the `ObserveAndDelete` policy, which is the default. This policy triggers Ansible content during `Observe()` for existing resources and during `Delete()` for absent resources. The `ansible_provider_meta` variable can be used to manage state differences.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  annotations:
    # ObserveAndDelete is the default policy
    ansible.crossplane.io/runPolicy: ObserveAndDelete
  name: gcpbucket
spec:
  forProvider:
    playbookInline: |
      ---
      - hosts: localhost
        pre_tasks:
          - name: Install requests python package on version 2.28.1
            ansible.builtin.pip:
              name: requests==2.28.1
              extra_args: --user
          - name: Install google-auth python package on version 2.12.0
            ansible.builtin.pip:
              name: google-auth==2.12.0
              extra_args: --user
        tasks:
          - name: create a gcp bucket
            google.cloud.gcp_storage_bucket:
              name: ansible-storage-module
              project: test-project
              auth_kind: serviceaccount
              service_account_file: gcp-credentials.json
              state: present
            # Use provider metadata to determine resource state
            when: ansible_provider_meta.gcpbucket.state == 'present'
  providerConfigRef:
    name: default
---
apiVersion: v1
kind: Secret
metadata:
  namespace: crossplane-system
  name: gcp-credentials
type: Opaque
data:
  credentials: QkFTRTY0RU5DT0RFRF9QUk9WSURFUl9DUkVEUw==
---
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    - filename: gcp-credentials.json
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: gcp-credentials
        key: credentials
  requirements: |
    ---
    collections:
      - name: google.cloud
        source: https://galaxy.ansible.com
        version: "1.0.2"

```

--------------------------------

### AnsibleRun with Inline Playbook

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Defines an Ansible playbook directly within the Kubernetes manifest for simple automation tasks or quick testing. This method avoids the need for external playbook repositories.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: example
spec:
  forProvider:
    # Inline playbook content - suitable for simple automation tasks
    playbookInline: |
      ---
      - hosts: localhost
        tasks:
          - name: ansibleplaybook-simple
            debug:
              msg: Your are running 'ansibleplaybook-simple' example
```

--------------------------------

### AnsibleRun with Inline Inventory

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Specifies custom Ansible inventory inline within the Kubernetes manifest to define target hosts for playbook execution. This allows running playbooks against specific hosts or groups without external inventory files.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: AnsibleRun
metadata:
  name: inline-inventory-remote-debug
spec:
  forProvider:
    # Inline inventory specifying target hosts
    inventoryInline: |
      127.14.1.2
    playbookInline: |
      ---
      - hosts: all
        tasks:
          - name: ansibleplaybook-simple
            debug:
              msg: Your are running 'ansibleplaybook-simple' example
```

--------------------------------

### Reference Ansible Variables in Playbooks (YAML)

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

Demonstrates how to reference variables defined in an AnsibleRun resource within Ansible playbooks or roles using Jinja2 syntax. Supports accessing simple variables, list elements, and dictionary fields.

```yaml
- name: An example to show the use of vars
  debug:
    msg: "Print {{ foo }}".
```

```yaml
- name: An example to show the use of vars
  debug:
    msg: "Print {{ bar[0] }}".
```

```yaml
- name: An example to show the use of vars
  debug:
    msg: "Print {{ baz['field1'] }}".
```

```yaml
- name: An example to show the use of vars
  debug:
    msg: "Print {{ baz.field2 }}".
```

--------------------------------

### ProviderConfig with Credentials and Requirements

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Configures provider-level settings for Ansible, including credentials for private repositories and requirements for Ansible collections. A single ProviderConfig can manage multiple credential sources and specify necessary collections.

```yaml
# Create a Secret for cloud provider credentials
apiVersion: v1
kind: Secret
metadata:
  namespace: crossplane-system
  name: gcp-credentials
type: Opaque
data:
  # Base64-encoded service account JSON
  credentials: QkFTRTY0RU5DT0RFRF9QUk9WSURFUl9DUkVEUw==
---
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: default
spec:
  # Multiple credentials can be specified for different providers
  credentials:
    - filename: gcp-credentials.json
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: gcp-credentials
        key: credentials
  # Requirements define Ansible collections to install
  requirements: |
    ---
    collections:
      - name: google.cloud
        source: https://galaxy.ansible.com
        version: "1.0.2"

```

--------------------------------

### ProviderConfig with Custom Variables

Source: https://context7.com/crossplane-contrib/provider-ansible/llms.txt

Configures provider-level environment variables to customize Ansible behavior. This allows specifying custom paths for roles and collections, influencing how Ansible finds and loads modules.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  # Provider-level variables for Ansible configuration
  vars:
    # Specify custom path for Ansible roles
    - key: ANSIBLE_ROLE_PATH
      value: /path/to/roles
    # Specify custom path for Ansible collections
    - key: ANSIBLE_COLLECTION_PATH
      value: /path/to/collections

```

--------------------------------

### Declare Ansible Roles and Collections Together - YAML

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This YAML snippet demonstrates how to declare both Ansible roles and collections within the same `ProviderConfig` resource. It shows how to specify requirements from Ansible Galaxy for both roles and collections.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: provider-config-example
spec:
  requirements: |
    ---
    roles:
      # Install a role from Ansible Galaxy.
      - name: sample_namespace.sample_role
        version: 0.1.0
    collections:
      # Install a collection from Ansible Galaxy.
      - name: sample_namespace.sample_collection
        version: 0.1.0
        source: https://galaxy.ansible.com
```

--------------------------------

### Define Ansible Collection Requirement in ProviderConfig

Source: https://github.com/crossplane-contrib/provider-ansible/blob/main/docs/design.md

This YAML defines the requirements for an Ansible collection within a Crossplane `ProviderConfig`. It specifies the collection name (`nginxinc.nginx_core`) and optionally its version. This configuration allows the Ansible provider to fetch and use the specified collection for running playbooks or roles.

```yaml
apiVersion: ansible.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: example
spec:
  requirements: |
    ---
    collections:
      - name: nginxinc.nginx_core
        version: 0.5.0
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.