4 Ansible playbooks you should try

Streamline and tighten automation processes in complex IT environments with these Ansible playbooks.
299 readers like this.
How Kubernetes became the solution for migrating legacy applications


In a complex IT environment, even the smallest tasks can seem to take forever. Sprawling systems are hard to develop, deploy, and maintain. Business demands only increase complexity, and IT teams struggle with management, availability, and cost.

How do you address this complexity and while meeting today's business demands? There is no doubt that Ansible can improve your current processes, migrate applications for better optimization, and provide a single language for DevOps practices across your organization.

More importantly, you can declare configurations through Ansible playbooks, but they orchestrate steps of any manual ordered process, even as different steps must bounce back and forth between sets of machines in particular orders. They can launch tasks synchronously or asynchronously.

While you might run the main /usr/bin/ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out your configuration or ensure the configurations of your remote systems are in spec. Because the Ansible playbooks are configuration, deployment, and orchestration language, they can describe a policy you want your remote systems to enforce or a set of steps in a general IT process.

Here are four Ansible playbooks that you should try to further customize and configure how your automation works.

Managing Kubernetes objects

When you perform CRUD operations on Kubernetes objects, Ansible playbooks enable you to quickly and easily access the full range of Kubernetes APIs through the OpenShift Python client. The following playbook snippets show you how to create specific Kubernetes namespace and service objects:

- name: Create a k8s namespace
    name: mynamespace
    api_version: v1
    kind: Namespace
    state: present

- name: Create a Service object from an inline definition
    state: present
      apiVersion: v1
      kind: Service
        name: web
        namespace: mynamespace
          app: galaxy
          service: web
          app: galaxy
          service: web
        - protocol: TCP
          targetPort: 8000
          name: port-8000-tcp
          port: 8000

- name: Create a Service object by reading the definition from a file
    state: present
    src: /mynamespace/service.yml

# Passing the object definition from a file
- name: Create a Deployment by reading the definition from a local file
    state: present
    src: /mynamespace/deployment.yml

Mitigate critical security concerns like Meltdown and Spectre

In the first week of January, two flaws were announced: Meltdown and Spectre. Both involved the hardware at the heart of more or less every computing device on the planet: the processor. There is a great in-depth review of the two flaws here. While Meltdown and Spectre are not completely mitigated, the following playbook snippets show how to easily deploy the patches for Windows:

- name: Patch Windows systems against Meltdown and Spectre
  hosts: "{{ target_hosts | default('all') }}"

    reboot_after_update: no
      - path: HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
        name: FeatureSettingsOverride
        data: 0
        type: dword

      - path: HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
        name: FeatureSettingsOverrideMask
        data: 3
        type: dword

      # https://support.microsoft.com/en-us/help/4072699
      - path: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat
        name: cadca5fe-87d3-4b96-b7fb-a231484277cc
        type: dword
        data: '0x00000000'

    - name: Install security updates
          - SecurityUpdates
      notify: reboot windows system

    - name: Enable kernel protections
        path: "{{ item.path }}"
        name: "{{ item.name }}"
        data: "{{ item.data }}"
        type: "{{ item.type }}"
      with_items: "{{ registry_keys }}"

    - name: reboot windows system
        shutdown_timeout: 3600
        reboot_timeout: 3600
      when: reboot_after_update

You can also find other playbooks for Linux.

Integrating a CI/CD process with Jenkins

Jenkins is a well-known tool for implementing CI/CD. Shell scripts are commonly used for provisioning environments or to deploy apps during the pipeline flow. Although this could work, it is cumbersome to maintain and reuse scripts in the long run. The following playbook snippets show how to provision infrastructure in a Continuous Integration/Continuous Delivery (CI/CD) process using a Jenkins Pipeline.

- name: Deploy Jenkins CI
hosts: jenkins_server
remote_user: vagrant
become: yes

  - geerlingguy.repo-epel
  - geerlingguy.jenkins
  - geerlingguy.git
  - tecris.maven
  - geerlingguy.ansible

- name: Deploy Nexus Server
hosts: nexus_server
remote_user: vagrant
become: yes

  - geerlingguy.java
  - savoirfairelinux.nexus3-oss

- name: Deploy Sonar Server
hosts: sonar_server
remote_user: vagrant
become: yes

  - wtanaka.unzip
  - zanini.sonar

- name: On Premises CentOS
hosts: app_server
remote_user: vagrant
become: yes

  - jenkins-keys-config

Starting a service mesh with Istio

With a cloud platform, developers must use microservices to architect for portability. Meanwhile, operators are managing extremely large hybrid and multi-cloud deployments. The service mesh with Istio lets you connect, secure, control, and observe services instead of developers through a dedicated infrastructure such as an Envoy sidecar container. The following playbook snippets show how to install Istio locally on your machine:


# Whether the cluster is an Openshift (ocp) or upstream Kubernetes (k8s) cluster
cluster_flavour: ocp

  # Install istio with or without istio-auth module
  auth: false

  # A set of add-ons to install, for example kiali
  addon: []

  # The names of the samples that should be installed as well.
  # The available samples are in the istio_simple_samples variable
  # In addition to the values in istio_simple_samples, 'bookinfo' can also be specified
  samples: []

  # Whether or not to open apps in the browser
  open_apps: false

  # Whether to delete resources that might exist from previous Istio installations
  delete_resources: false


You can find full sets of playbooks that illustrate many of these techniques in the ansible-examples repository. I recommend looking at these in another tab as you go along.

Hopefully, these tips and snippets of Ansible playbooks have provided some interesting ways to use and extend your automation journey.

Technical Marketing, Developer Advocate, CNCF Ambassador, Public Speaker, Published Author, Quarkus, Red Hat Runtimes


Very Useful!!

What do you mean by "The service mesh with Istio lets you connect, secure, control, and observe services instead of developers through a dedicated infrastructure such as an Envoy sidecar container"?
It sounds like you're saying that you want to "...observe services instead of developers" and that makes no sense to me.

Before Istio service mesh, developers have to implement non-functional capabilities like client load balancing, service discovery, service registry, tracing, etc. on Spring Boot, Netflix OSS stuff. After Istio, envoy sidecar container(aka a dedicated infrastructure) will address those of capabilities which means the developers are now focusing on implementation of business logic. Hopefully, it makes you clarify the paragraph.

In reply to by rgwertg (not verified)

Thanks for sharing!

Daniel, these snippets are so tight that in isolation I don't think they are useful to anyone. Are you really saying that the istio example ansible code above by itself will allow a full installation of istio? how? Thanks and apologies in advance if I have misunderstood.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.