Forem: Martez Reed

Installing Puppet Enterprise 2021

Martez Reed — Mon, 20 Dec 2021 03:56:06 +0000

Puppet is a popular open source configuration management tool for managing the configuration of systems using declarative code. Puppet Enterprise is the commercial distribution or version of Puppet that includes enterprise features like RBAC, a Web UI, and more features. Puppet Enterprise provides a free trial of the platform for use on up to 10 nodes. In this blog post we’ll walk through installing the latest release of Puppet Enterprise.

Getting Started

Verify system requirements
Download the Puppet Enterprise installer
Install Puppet Enterprise 2021

Verify System Requirements

The first thing we need to do is verify the system requirements for installing Puppet Enterprise. The Puppet Enterprise primary server supports installation on most of the popular linux distributions.

Hardware Requirements: https://puppet.com/docs/pe/2021.4/hardware_requirements.html#hardware-requirements

Software Requirements: https://puppet.com/docs/pe/2021.4/supported_operating_systems.html#supported_operating_systems

Download Puppet Enterprise

Now that the system requirements have been verified we need to download the Puppet Enterprise installer. To download the installer, go to the Puppet website to access the free 10 node trial (https://puppet.com/try-puppet/puppet-enterprise).

Once you have provided your information you will then be redirected to the installer download page. This page includes packages for the primary server along with the agents. Click the CURL or WGET button next to the desired operating system to copy the curated command to your clipboard.

Now we just need to run the curl or wget command on the system we’ll designated for the Puppet Enterprise installation.

Install Puppet Enterprise

Installing Puppet Enterprise is a pretty simple and straightforward process that should take a few minutes depending upon the system hardware.

Untar the Puppet Enterprise installer tarball

tar -xzf puppet-enterprise-2021.4.0-el-7-x86_64.tar.gz

Change the working directory to the unpacked installer directory

cd puppet-enterprise-2021.4.0-el-7-x86_64

Run the Puppet Enterprise installer

./puppet-enterprise-installer

Set the Puppet Enterprise console password once the installer has completed successfully

puppet infrastructure console_password --password=REPLACE_ME

With the installation successfully completed we can now access the Puppet Enterprise web console by opening a web browser to the IP address or FQDN of the server via HTTPS. The username is admin and the password is the password specified in the previous step.

Deploying Kuma Service Mesh with Puppet Bolt

Martez Reed — Mon, 05 Apr 2021 15:38:27 +0000

Kuma is a platform agnostic open-source control plane for service mesh and microservices management, with support for Kubernetes, VM, and bare metal environments. Kubernetes has quickly become the de facto platform on which new applications are being built to take advantage of the benefits that come with containerization. The challenge that many organizations are facing is integrating containerized workloads in Kubernetes with VM based workloads in a meaningful way. In this case Kuma service mesh can be used to provide the benefits of service mesh in a k8s/vm hybrid scenario.

In this blog post we’ll take a look at how to use Puppet Bolt to deploy the universal version of the Kuma service mesh control plane intended for virtual machines.

Initialize the Bolt project

Ensure that the latest version of Puppet Bolt is installed before getting started.

Puppet Bolt utilizes Project directories as launching points for running Bolt operations. Create a directory for our Puppet Bolt project name kumamesh.

mkdir kumamesh

Change the working directory to kumamesh directory

cd kumamesh

Now that we have a directory for hosting our Bolt project, we need to initialize the project.

bolt project init

Add the puppet-kuma module from the associated Github repository to the bolt-project.yaml file.

--------
name: kumamesh
modules:
  - git: [https://github.com/martezr/puppet-kuma.git](https://github.com/martezr/puppet-kuma.git)
    ref: 'main'

Install the module and its dependencies.

bolt module install

Create the Bolt plan

In order to utilize plans in Bolt, we need to create a directory named plans.

mkdir plans

Now that we have our plans directory created we’ll use the Kuma service mesh module to install the Kuma service mesh control plane backed by a PostgreSQL database.

Create a file named controlplane.pp with the following content in the plans directory.

plan kumamesh::controlplane (
  TargetSpec $targets
) {
  apply_prep($targets)
  apply($targets){

    class { 'kuma':
      version => '1.1.1',
    }

    class { 'kuma::controlplane':
      manage_postgres => true,
    }
  }
}

Now that we’ve created our plan we can ensure that it’s recognized by Bolt by running the following command.

bolt plan show

If the plan registers properly the output should include a kumamesh_::controlplane_ entry.

Plans
  aggregate::count                    
  aggregate::targets                  
  canary                              
  facts                               
  facts::external                     
  facts::info                         
  **kumamesh::controlplane**              
  puppet_agent::run                   
  puppet_connect::test_input_data     
  puppetdb_fact                       
  reboot                              
  secure_env_vars                     
  terraform::apply
  terraform::destroy

With the plan registered we are now ready to run the plan by running the bolt plan run kumamesh::controlplane command. We’ve specified the target which is the node we want to install the control plane on. In this example we’ve used IP addresses but resolvable hostnames could have been used as well.

bolt plan run kumamesh::controlplane --target 10.0.0.111

If the plan ran successfully it should have generated output similar to that displayed below.

Starting: plan kumamesh::controlplane
Starting: install puppet and gather facts on 10.0.0.111
Finished: install puppet and gather facts with 0 failures in 12.07 sec
Starting: apply catalog on 10.0.0.111
Finished: apply catalog with 0 failures in 53.15 sec
Finished: plan kumamesh::controlplane in 1 min, 6 sec
Plan completed successfully with no result

Plan completed successfully with no result

Once the plan has completed successfully we can now view the control plane GUI by browsing to http://controlplane_ip:5681/gui.

Deploying HashiCorp Consul Agents With Puppet Bolt

Martez Reed — Mon, 07 Dec 2020 15:17:42 +0000

HashiCorp Consul is an open source tool that solves these new complexities by providing service discovery, health checks, load balancing, a service graph, mutual TLS identity enforcement, and a configuration key-value store.

Service discovery is the Consul feature we’ll focus on in this blog post. Service discovery is particularly important in environments where workloads are more ephemeral than the traditional server that runs for years. Service discovery is very similar to how we think of name resolution using DNS but with a richer set of features.

Workloads register themselves and their services through agents
Consul enables health checks to be used for checking the health of a service

Consul is a distributed system that is composed of servers and clients. This blog post assumes that a server or group of servers have already been deployed and now clients need to be deployed.

HashiCorp Consul Architecture

In this blog post we’ll take a look at how to use Puppet Bolt to deploy a Consul agent alongside an NGINX web server and register it as a service in Consul.

Initialize the Bolt project

Ensure that the latest version of Puppet Bolt is installed before getting started.

Puppet Bolt utilizes Project directories as launching points for running Bolt operations. Create a directory for our Puppet Bolt project name consuldeploy.

mkdir consuldeploy

Change the working directory to consuldeploy directory

cd consuldeploy

Now that we have a directory for hosting our Bolt project, we need to initialize the project.

bolt project init --modules kyleanderson-consul, puppet-nginx

Create the Bolt YAML plan

In order to utilize plans in Bolt, we need to create a directory named plans.

mkdir plans

Now that we have our plans directory created we’ll plan out what we want to accomplish as part of our plan. We’ll accomplish the following tasks:

Deploy NGINX
Install unzip to unzip the consul agent zip file
Install the Consul agent
Register the web service in Consul

We’ve got a plan of what we want to do and now we are ready to create the Bolt plan.

Create a file named consul_agent.yaml with the following content in the plans directory. The plan includes four parameters that are used to specify various configurations.

---
parameters:
  targets:
    type: TargetSpec
  consul_datacenter:
    type: String
    description: "The consul datacenter to join"
    default: puppet-bolt
  consul_agent_version:
    type: String
    description: "The consul agent version to install"
    default: 1.9.0
  consul_servers:
    type: Array[String]
    description: "An array of consul servers to connect to"

steps:
  - name: installnginx
    targets: $targets
    resources:
      - class: nginx
  - name: deployconsul
    targets: $targets
    resources:
      - package: unzip
        parameters:
          ensure: latest
      - class: consul
        parameters:
          version: $consul_agent_version
          config_hash:
            data_dir: '/opt/consul'
            datacenter: $consul_datacenter
            retry_join: $consul_servers
          services:
            web:
              checks:
                - http: http://localhost
                  interval: 10s
                  timeout: 5s
              port: 80
              tags:
                - web
                - nginx

Now that we’ve created our plan we can ensure that it’s recognized by Bolt by running the following command.

bolt plan show

If the plan registers properly the output should include a consuldeploy::consul_agent_ entry.

aggregate::count
aggregate::nodes
aggregate::targets
canary
consuldeply::consul_agent
facts
facts::external
facts::info
puppet_agent::run
puppetdb_fact
reboot  
secure_env_vars
terraform::apply
terraform::destroy

With the plan registered we are now ready to run the plan by running the bolt plan run consuldeploy::consul_agent command. We’ve specified the target which is the node we want to install the consul agent on as well as an array of consul servers. In this example we’ve used IP addresses but resolvable hostnames could have been used as well.

bolt plan run consuldeploy::consul_agent --target 10.0.0.123 consul_servers='["10.0.0.193"]'

If the plan ran successfully it should have generated output similar to that displayed below.

Starting: plan consuldeploy::consul_agent
Starting: install puppet and gather facts on 10.0.0.123
Finished: install puppet and gather facts with 0 failures in 24.97 sec
Starting: apply catalog on 10.0.0.123
Finished: apply catalog with 0 failures in 20.06 sec
Starting: install puppet and gather facts on 10.0.0.123
Finished: install puppet and gather facts with 0 failures in 3.37 sec
Starting: apply catalog on 10.0.0.123
Finished: apply catalog with 0 failures in 22.18 sec
Finished: plan consuldeploy::consul_agent in 1 min, 12 sec
Plan completed successfully with no result

Once the plan has completed successfully we can now view the web service in the consul server dashboard.

This blog post has shown the basic consul agent configuration using Puppet Bolt but the consul module on the Puppet Forge that was used in this post highlights additional settings and configuration options that can be configured.

Deploy a Node application using Puppet Bolt

Martez Reed — Tue, 10 Nov 2020 15:01:13 +0000

Application deployment is a multi-step process that can even include touching multiple machines or systems. In this blog post we’ll look at how we can use Puppet Bolt to deploy a node application. The application is a simple todo application created by scotch.io that is composed of a node application and a mongodb database. We’ll deploy the application and database on separate servers to show how this can be handled with Puppet Bolt.

We’ll create three (3) Bolt plans that will each be used for a different part of the automation. At a high level we want to install the mongodb database on our database virtual machine and then install our node application on the app virtual machine.

Plan Overview

todoapp : The todoapp plan will be the overarching plan that actually handles the orchestration of the application deployment.
db : The db plan installs the mongodb database on the database server virtual machine.
app : The app plan installs node, npm, git and other prerequisites on the application server virtual machine.

Forge modules

The deployment plan uses the following Puppet Forge modules to deploy the application stack.

puppet/mongodb
puppet/nodejs
camptocamp/systemd
puppetlabs/vcsrepo
puppet/firewalld

Initialize the Bolt project

Ensure that the latest version of Puppet Bolt is installed before getting started.

Puppet Bolt utilizes Project directories as launching points for running Bolt operations. Create a directory for our Puppet Bolt project name nodeproject.

mkdir nodeproject

Change the working directory to nodeproject directory

cd nodeproject

Now that we have a directory for hosting our Bolt project, we need to initialize the project.

bolt project init --modules puppet-mongodb,puppet-nodejs,camptocamp-systemd,puppetlabs-vcsrepo,puppet-firewalld

The command should generate output similar to that shown below if it ran successfully.

Installing project modules

→ Resolving module dependencies, this may take a moment

→ Writing Puppetfile at

/system/path/nodeproject/Puppetfile

→ Syncing modules from

/system/path/nodeproject/Puppetfile to

/system/path/nodeproject/modules

→ Generating type references

Successfully synced modules from /system/path/nodeproject/Puppetfile to /system/path/nodeproject/modules

Successfully created Bolt project at /system/path/nodeproject

Create the Bolt YAML plan

In order to utilize plans in Bolt, we need to create a directory named plans.

mkdir plans

Now that we have our plans directory created we’ll plan out what we want to accomplish as part of our plan.

The first thing we’ll do is create the todoapp plan that will call the app and db plans. The name of the sub or nested plans are app and db which are referenced in our plan by the name of the bolt project and the plan (bolt_project::bolt_plan). The plan accepts two parameters ( app, db ) that specify the IP address or FQDN of the virtual machines used for the application and database.

---
parameters:
  app:
    type: TargetSpec
  db:
    type: TargetSpec

steps:
  - plan: nodeproject::db
    description: "Deploy todo node application mongodb database"
    parameters:
      db_targets: $db
  - plan: nodeproject::app
    description: "Deploy todo node application"
    parameters:
      app_targets: $app
      db_targets: $db

Now that we’ve got the todoapp plan in place we need to create the db plan to install the mongodb database. Create another plan in the plans directory named db.yaml.

Steps

Configure mongodb yum repository
Install mongodb
Create firewalld rule for mongodb (port 27017)

---
parameters:
  db_targets:
    type: TargetSpec

steps:
  - name: installmongo
    targets: $db_targets
    resources:
    - class: mongodb::globals
      parameters:
        version: 4.2.0
        manage_package_repo: true
        server_package_name: mongodb-org-server
        bind_ip: [0.0.0.0]
    - class: mongodb::server
      parameters:
        port: 27017
  - name: configurefirewall
    targets: $db_targets
    resources:
    - class: firewalld
    - firewalld_zone: 'public'
      parameters:
        ensure: present
        purge_ports: true
    - firewalld_port: 'node db'
      parameters:
        ensure: present
        port: 27017
        protocol: tcp

Finally, we’re ready to create the app plan to deploy the node application. Deploying the node application requires a number of steps to actually get the application running. The plan accepts the IP address or DNS name of the application virtual machine and the database virtual machine as parameters.

Install the git package
Create a firewalld rule for the node application (port 8080)
Clone the node-todo git repository
Install node and npm
Install the node-todo application packages (npm install)
Write the database configuration file
Create a systemd unit file for the node application
Reload the systemd daemon to recognize the unit file changes
Start the todo-app service

---
parameters:
  app_targets:
    type: TargetSpec
  db_targets:
    type: String

steps:
  - name: installprerequisites
    description: "install app prerequisite software"
    targets: $app_targets
    resources:
    - package: git
      parameters:
        ensure: present
  - name: configurefirewall
    targets: $app_targets
    resources:
    - class: firewalld
    - firewalld_zone: 'public'
      parameters:
        ensure: present
        purge_ports: true
    - firewalld_port: 'node app'
      parameters:
        ensure: present
        port: 8080
        protocol: 'tcp'
  - name: installtodoapp
    targets: $app_targets
    resources:
    - vcsrepo: '/opt/node-todo'
      parameters:
        ensure: present
        provider: git
        source: '[https://github.com/scotch-io/node-todo.git'](https://github.com/scotch-io/node-todo.git')
        trust_server_cert: true
    - class: nodejs
    - nodejs::npm: 'app'
      parameters:
        ensure: present
        target: /opt/node-todo
        use_package_json: true
    - file: '/opt/node-todo/config/database.js'
      parameters:
        ensure: present
        content: >
          module.exports = {
            remoteUrl : "mongodb://$db_targets:27017/uwO3mypu",
            localUrl: "mongodb://$db_targets:27017/meanstacktutorials"
          };
    - file: '/etc/systemd/system/todo-app.service'
      parameters:
        ensure: present
        content: >
          [Unit]

          Description=Todo node application

          Documentation=[https://github.com/scotch-io/node-todo](https://github.com/scotch-io/node-todo)

          After=network.target

          [Service]

          Type=simple

          WorkingDirectory=/opt/node-todo

          ExecStart=/usr/bin/npm start

          Restart=on-failure

          [Install]

          WantedBy=multi-user.target
        notify: Class[systemd::systemctl::daemon_reload]
    - class: systemd::systemctl::daemon_reload
    - service: 'todo-app'
      parameters:
        ensure: running
        subscribe: File[/etc/systemd/system/todo-app.service]

Now that we’ve created our plans we can ensure that it’s recognized by Bolt by running the following command.

bolt plan show

If the plan registers properly the output should include the following entries.

nodeproject::todoapp
nodeproject::app
nodeproject::db

aggregate::count
aggregate::nodes
aggregate::targets
canary
facts
facts::external
facts::info
nodeproject::app  
nodeproject::db  
nodeproject::todoapp
puppet_agent::run
puppetdb_fact
reboot
secure_env_vars
terraform::apply
terraform::destroy
secure_env_vars
terraform::apply
terraform::destroy

With the plans registered we are now ready to run the todoapp plan by running the bolt plan run nodeproject::todoapp command. The plan.

bolt plan run nodeproject::todoapp app=10.0.0.41 db=10.0.0.42

If the plan ran successfully it should have generated output similar to that displayed below.

Starting: plan nodeproject::todoapp
Starting: plan nodeproject::db
Starting: install puppet and gather facts on 10.0.0.42
Finished: install puppet and gather facts with 0 failures in 74.59 sec
Starting: apply catalog on 10.0.0.42
Finished: apply catalog with 0 failures in 35.91 sec
Starting: install puppet and gather facts on 10.0.0.42
Finished: install puppet and gather facts with 0 failures in 8.03 sec
Starting: apply catalog on 10.0.0.42
Finished: apply catalog with 0 failures in 19.44 sec
Finished: plan nodeproject::db in 2 min, 18 sec
Starting: plan nodeproject::app
Starting: install puppet and gather facts on 10.0.0.41
Finished: install puppet and gather facts with 0 failures in 74.78 sec
Starting: apply catalog on 10.0.0.41
Finished: apply catalog with 0 failures in 25.49 sec
Starting: install puppet and gather facts on 10.0.0.41
Finished: install puppet and gather facts with 0 failures in 7.59 sec
Starting: apply catalog on 10.0.0.41
Finished: apply catalog with 0 failures in 18.23 sec
Starting: install puppet and gather facts on 10.0.0.41
Finished: install puppet and gather facts with 0 failures in 8.9 sec
Starting: apply catalog on 10.0.0.41
Finished: apply catalog with 0 failures in 65.48 sec
Finished: plan nodeproject::app in 3 min, 21 sec
Finished: plan nodeproject::todoapp in 5 min, 40 sec
Plan completed successfully with no result

Once the command completes successfully we can check that everything worked by opening entering the IP address or FQDN of the Bolt target in a web browser. The site should show the following message.

We have now successfully deployed a node application using Puppet Bolt. The automation can be made more elaborate such as interacting with a load balancer, performing database prep operations or more.

Using Puppet Bolt with REST APIs

Martez Reed — Mon, 02 Nov 2020 14:11:49 +0000

Puppet Bolt Logo

Puppet Bolt is an open source automation and orchestration tool. One of the common tasks in an orchestration workflow is interacting with an external system using a REST API. This could be something like creating a user or updating a record in a CMDB. A built-in task for making HTTP request calls was added in Bolt 2.30.0 and JSON output parsing was added in Bolt 2.32.0. This enables us to quickly add a step to a plan to integrate with a REST API endpoint. In this blog post we’ll walk through how to fetch data (GET request) and submit data (POST request) using the HashiCorp Vault API to show the interaction.

HashiCorp Vault Setup

HashiCorp Vault is bundled as a compiled binary that can be run easily by simply downloading the binary from the HashiCorp Vault download page. Unzip the download bundle, set the vault binary to be executable on linux or mac os x and finally run the following command to start Vault.

In this example the Vault root token is being manually set to “vaultsecret”.

vault server -dev -dev-root-token-id="vaultsecret"

Initialize the Bolt project

Ensure that the latest version of Puppet Bolt is installed before getting started.

Puppet Bolt utilizes Project directories as launching points for running Bolt operations. Create a directory for our Puppet Bolt project name restproject.

mkdir restproject

Change the working directory to restproject directory

cd restproject

Now that we have a directory for hosting our Bolt project, we need to initialize the project.

bolt project init

The command should generate output similar to that shown below if it ran successfully.

Create the Bolt YAML plan

In order to utilize plans in Bolt, we need to create a directory named plans.

mkdir plans

Now that we have our plans directory created we’ll plan out what we want to accomplish as part of our plan. We’ll keep this plan as simple as possible to show how easy it is to use Puppet Bolt to make API calls. We’ll accomplish the following tasks:

Write a static password to HashiCorp Vault (POST method)
Read the static password created from HashiCorp Vault (GET method)

Interacting with the Vault API

The API endpoint requires authentication which is why we are passing a X-Vault-Token header with the Vault root token.
The Vault API returns a JSON payload and the json_endpoint parameter for the read step has been set to true to properly parse the returned JSON.

We’ve got a plan of what we want to do and now we are ready to create the Bolt plan.

Create a file named api.yaml with the following content in the plans directory.

---
parameters:
  targets:
    type: TargetSpec

steps:
  - name: write_password
    task: http_request
    targets: $targets
    parameters:
      method: post
      body: '{"data": {"password": "supersecurepassword"}}'
      base_url: '[http://localhost:8200/v1/secret/data/boltsecret'](http://localhost:8200/v1/secret/data/boltsecret')
      headers:
        Content-Type: application/json
        X-Vault-Token: 'vaultsecret'
  - name: read_password
    task: http_request
    targets: $targets
    parameters:
      method: get
      base_url: '[http://localhost:8200/v1/secret/data/boltsecret'](http://localhost:8200/v1/secret/data/boltsecret')
      json_endpoint: true
      headers:
        Content-Type: application/json
        X-Vault-Token: 'vaultsecret'

return: $read_password.first.value['body']['data']['data']['password']

The original JSON payload returned from HashiCorp Vault is displayed below for the purposes of understanding the JSON parsing used to return just the password value.

{
    "body": {
      "request_id": "e896d6c8-20c3-02ee-ccd7-b97778217acb",
      "lease_id": "",
      "renewable": false,
      "lease_duration": 0,
      "data": {
        "data": {
          "password": "supersecurepassword"
        },
        "metadata": {
          "created_time": "2020-10-31T17:06:54.890898Z",
          "deletion_time": "",
          "destroyed": false,
          "version": 1
        }
      },
      "wrap_info": null,
      "warnings": null,
      "auth": null
    },
    "status_code": 200
  }

Now that we’ve created our plan we can ensure that it’s recognized by Bolt by running the following command.

bolt plan show

If the plan registers properly the output should include a restproject::api entry.

aggregate::count
aggregate::nodes
aggregate::targets
canary
facts
facts::external
facts::info
puppet_agent::run
puppetdb_fact
reboot
restproject::api  
secure_env_vars
terraform::apply
terraform::destroy

With the plan registered we are now ready to run the plan by running the bolt plan run restproject::api command. The target for the plan is localhost as we want to run the API call from the machine we are running Bolt on.

bolt plan run restproject::api --target localhost

If the plan ran successfully it should have generated output similar to that displayed below.

Starting: plan restproject::api
Starting: task http_request on localhost
Finished: task http_request with 0 failures in 0.26 sec
Starting: task http_request on localhost
Finished: task http_request with 0 failures in 0.26 sec
Finished: plan restproject::api in 0.57 sec
"supersecurepassword"

If the plan completed successfully the value of the password created in the first step should be returned.

This example walked through how to interact with REST API endpoints using the http_request task that is included with Puppet Bolt.

Automate in YAML with Puppet Bolt

Martez Reed — Wed, 21 Oct 2020 17:44:59 +0000

Automate in YAML with Puppet Bolt

The Puppet DSL or Domain Specific Language is one of the things most associated with Puppet. A number of other automation tools make use of a DSL such as HashiCorp Terraform which uses HCL or HashiCorp Configuration Language.

One of the most interesting things about Puppet Bolt is its ability to support the Puppet DSL but also YAML. YAML is quicker to adopt especially for those already familiar with YAML.

In this post we’ll take a look at how to quickly get started with a YAML plan by deploying a simple website using NGINX.

Initialize the Bolt project

Ensure that the latest version of Puppet Bolt is installed before getting started.

Puppet Bolt utilizes Project directories as launching points for running Bolt operations. Create a directory for our Puppet Bolt project name webapp.

mkdir webapp

Change the working directory to webapp directory

cd webapp

Now that we have a directory for hosting our Bolt project, we need to initialize the project and also add the NGINX Puppet module from the Puppet Forge.

bolt project init --modules puppet-nginx

The command should generate output similar to that shown below if it ran successfully.

Installing project modules

→ Resolving module dependencies, this may take a moment

→ Writing Puppetfile at
    /system/path/webapp/Puppetfile

→ Syncing modules from
    /system/path/webapp/Puppetfile to
    /system/path/webapp/modules

Successfully synced modules from /system/path/webapp/Puppetfile to /system/path/webapp/modules
Successfully created Bolt project at /system/path/webapp

Create the Bolt YAML plan

In order to utilize plans in Bolt, we need to create a directory named plans.

mkdir plans

Now that we have our plans directory created we’ll plan out what we want to accomplish as part of our deployment. We’ll keep this plan as simple as possible to show how easy it is to use YAML with Puppet Bolt. We’ll accomplish the following tasks

Install NGINX
Create an HTML file using content specified

We’ve got a plan of what we want to do and now we are ready to create the Bolt plan. We’ll dig into the basic syntax of a Bolt YAML plan to understand the following Bolt Plan.

Create a file named deploy.yaml with the following content.

parameters:
  targets:
    type: TargetSpec

steps:
  - name: installnginx
    targets: $targets
    resources:
      - class: nginx
  - name: deploycontent
    targets: $targets
    resources:
      - file: /usr/share/nginx/html/index.html
        parameters:
          ensure: present
          content: '<!DOCTYPE html><html><body><h1>My Puppet Bolt Site</h1><p>I used Bolt to deploy a website.</p></body></html>'

Plan Syntax

The plan above includes two sections which are parameters and steps.

Parameters allow us to pass values to the plan, in this case our plan accepts a parameter named targets with a type of TargetSpec. This is used to pass the IP address or FQDN of the machine or machines that we want to run the plan against.

Steps as the name implies are the steps that we want to run against the machine. The plan above includes two stepsThe following

Message: The message step is used to print a message.
Command: The command step is used to run a command against the target or targets.
Task: The task step is used to run a Bolt task against the target or targets.
Script: The script step is used to run a script against the target or targets.
File Download: The file download step is used to download a file from the target or targets to the system that Bolt is running on.
File Upload: The file upload step is used to upload a file from the system that Bolt is running on to the target or targets.
Plan: The plan step is used to run other plans as part of a plan (nested plans).
Resources: The resource step is used apply Puppet resources to the target or targets.

Now that we’ve created our plan we can ensure that it’s recognized by Bolt by running the following command.

bolt plan show

If the plan registers properly the output should include a webapp::deploy entry.

aggregate::count
aggregate::nodes
aggregate::targets
canary
facts
facts::external
facts::info
puppet_agent::run
puppetdb_fact
reboot
secure_env_vars
terraform::apply
terraform::destroy
**webapp::deploy**

With the plan registered we are now ready to run the plan by running the bolt plan run webapp::deploy command.

bolt plan run webapp::deploy --targets web01.grt.local --no-host-key-check --user root

If the plan ran successfully it should have generated output similar to that displayed below.

Starting: plan webapp::deploy
Starting: install puppet and gather facts on 10.0.0.40
Finished: install puppet and gather facts with 0 failures in 12.3 sec
Starting: apply catalog on 10.0.0.40
Finished: apply catalog with 0 failures in 72.64 sec
Starting: install puppet and gather facts on 10.0.0.40
Finished: install puppet and gather facts with 0 failures in 7.01 sec
Starting: apply catalog on 10.0.0.40
Finished: apply catalog with 0 failures in 15.02 sec
Finished: plan webapp::deploy in 1 min, 48 sec
Plan completed successfully with no result

Once the command completes successfully we can check that everything worked by opening entering the IP address or FQDN of the Bolt target in a web browser. The site should show the following message.

We have now successfully deployed a website using Puppet Bolt. The automation can be made more elaborate such as downloading the web files from a git repository or uploading a directory of files.

Additional information about Puppet Bolt YAML plans can be found here.

Terraform is not Ansible or Puppet

Martez Reed — Wed, 14 Oct 2020 13:44:53 +0000

Terraform is not Ansible or Puppet

There’s a common misconception that Terraform does the exact same thing as Ansible, Puppet or other tools that fall into the configuration management category. The focus of this post is on detailing why this is a misconception even though some believe it to be fact.

Before we get started HashiCorp pretty much settles the debate for us. The following is pulled directly from the HashiCorp Terraform documentation.

Terraform is not a configuration management tool, and it allows existing tooling to focus on their strengths: bootstrapping and initializing resources. — https://www.terraform.io/intro/vs/chef-puppet.html

This statement explains some of the ethos that has been followed by the Terraform team. Even with that, the delineation between the two is not readily apparent as there are things Terraform can do that Ansible or Puppet does and vice versa.

So what is Terraform good at?

Terraform is great with APIs

Terraform is built to interface with REST APIs. Terraform creates resources by calling a REST API endpoint to perform CRUD (create, read, update, delete) operations.

Cloud Infrastructure

Terraform is an excellent tool for codifying cloud infrastructure such as AWS S3 buckets or Azure AKS clusters. Terraform also has providers for VMware vSphere and OpenStack to codify private cloud infrastructure. All of these provide a REST API for creating, reading, updating and deleting resources so Terraform is great at this.

But can’t Ansible and Puppet create cloud resources?

Yes, Ansible and Puppet can also be used to create cloud resources. Which tool you use to provision cloud resources comes down to preference. Typically you would evaluate which tool supports all the resources you anticipate creating as well as how you like creating the resources with that tool.

Application Configuration

This is where things can get really confusing. Most modern applications expose a REST API for configuring the application. Since we know that Terraform interacts with REST APIs then it can be used to configure applications.

But can’t Ansible and Puppet also configure applications?

Yes, Ansible and Puppet are also capable of configuring applications. Where things diverge is that Ansible and Puppet are ideally suited for installing the applications on the operating system unlike Terraform. This is also why it would make sense to use Ansible or Puppet to install and configure the application otherwise there could be a ping ponging between the tools in a provisioning pipeline ( Terraform [Infrastructure] -> Puppet [Application Install] -> Terraform [Application Configuration]). Technically Terraform can be used to install software or configure system settings but based upon the HashiCorp statement above, that’s not the focus for Terraform.

Terraform is not great at installing software or configuring operating system level settings.

But that’s not true, public cloud readily supports configuration at boot time by passing a script

It is true that Terraform can pass scripts or commands that are executed on a virtual machine or cloud instance at boot time. This model works well for smaller scripts but can become unwieldy once the script grows to some substantial size. Additionally, with some cloud init or userdata integrations there is no direct feedback regarding the status of the script. This means that you need those execution logs to be shipped to a centralized logger or connect directly to the machine to review them.

But terraform has remote exec resources so I can just use one of those instead?

Using a remote exec does provide that realtime execution feedback however, HashiCorp recommends against using remote exec resources when possible.

Provisioners should only be used as a last resort. For most common situations there are better alternatives. — https://www.terraform.io/docs/provisioners/remote-exec.html

This isn’t to say that they aren’t used quite frequently with great success but that it’s not an ideal solution.

This isn’t to say that Terraform can’t be used to install applications or configure operating system level settings but that that’s not what it is great at. Configuration management tools are great at doing those things and I’ll walk through some of the benefits.

Benefits of configuration management

Configuration management tools have a number of benefits in comparison to bash or powershell scripts but we’ll cover three that should be familiar to those that use Terraform.

Configuration As Code

Terraform utilizes HCL (HashiCorp Configuration Language) to define resources. Defining configuration as code is a paradigm that many have adopted and love, which is why they use Terraform. Remote execs and userdata integrations break from this model and relies on inline commands or scripts. Configuration management tools like Ansible and Puppet enable this “as code” paradigm to be used for system configuration as well.

State management (Idempotency)

Terraform utilizes the construct of state to provide idempotency. This means that when you run a terraform plan and the Terraform code matches the current state of the resource you anticipate that Terraform won’t change anything.

Idempotency is the ability for automation to be run multiple times and only change what needs to be changed. This is how Terraform works, it verifies the current state of the resource and makes changes only when when the state doesn’t match the configuration. Terraform remote execs and userdata integration address idempotency by running the automation only during provisioning. This is a core aspect of configuration management tools and allows the automation to be run multiple times.

State Correction (Desired State)

One of the reasons people love declarative tools is the ability to change a configuration by simply changing the value of a parameter. When you change a setting in Terraform and run terraform plan you anticipate Terraform to show that there’s a change to be made. Once you run a terraform apply you expect the setting to be changed to align with the newly declared setting. The advantage of this is that you don’t have to concern yourself with all of the details of how to actually update a resource.

Configuration management tools can update resources in a similar manner along with being used to correct configuration drift. Configuration drift is typically caused by manual changes or another tool making changes. This is capability helps ensure that systems stay in alignment with the declared configuration and is especially useful for security and regulatory compliance.

Conclusion

Ultimately, Terraform “can” do a lot of things Ansible or Puppet does but many of the reasons for using Terraform are the same reasons to use a configuration management tool in conjunction with Terraform.

Configuration Management in a Service Mesh World

Martez Reed — Fri, 02 Oct 2020 17:13:21 +0000

CNCF Service Mesh

Configuration Management in a Service Mesh World

In the IT space one could say that kubernetes is eating the IT world and it’s bringing an entire ecosystem to the table. One of the dinner guests is service mesh.

In a world with kubernetes and containers and microservices, why would we need configuration management?

Many organizations are embarking on the journey to kubernetes nirvana and taking advantage of all the many benefits that a service mesh can provide. Similar to a public cloud journey it’s when you get past the low hanging fruit or net new applications that the sheer complexity starts to become apparent.

We need to have our kubernetes workloads integrate with our “legacy” applications in a meaningful way.

Applications running on bare metal and virtual machines will now need to be connected to the service mesh to take advantage of all the benefits we love about service mesh. Integrating these workloads into the service mesh can be as simple as installing the service mesh agents on the VM or bare metal machine or involve standing up service mesh infrastructure for the non-kubernetes workloads and federating the two environments.

Many of the major service mesh projects already have non-kubernetes support to varying degrees.

Great, we can just install the service mesh agent on the virtual machine or bare metal machine. No reason for configuration management.

Unfortunately the process to bootstrap a VM or bare metal machine isn’t that simple for most service meshes. There are a number of operations to bootstrap the agent that are automagically done for workloads running on kubernetes but not for non-kubernetes workloads. Configuration management tools such as Puppet, Chef and Ansible are ideally suited to help with automating the bootstrap process.

Certificate management

Mutual TLS or mTLS between service endpoints is one of the major benefits of service meshes. This enables encrypted communication between services as well as the ability to restrict which services can talk based upon their identity. Many of the service meshes come with a built-in Certificate Authority (CA) to handle the certificate management process. Most are integrated with the assumption that the primary use case is kubernetes workloads and certificate distribution for non-kubernetes workloads is a manual process. Additionally, external certificate authorities are also supported but then there’s a completely different certificate bootstrap process that needs to be automated.

Configuration Management’s Role

Configuration management tools can help with the automated generation and distribution of the certificates used with the service mesh. It also can make integration with external certificate authorities like HashiCorp Vault simpler with the various existing integration with configuration management tools.

Micro segmentation

Micro segmentation is essentially granting workloads or services the ability to talk to other services on a need to communicate basis. The common example is a three tier application stack with web, app and database tiers. The web servers don’t need to send traffic to one another or the database servers. Similarly the database server shouldn’t need to send traffic to the web servers. This helps mitigate unfettered lateral movement in the event of a security breach.

Service Mesh Policies

Service meshes enable the ability to restrict which services are allowed to communicate with another service. In this way we can ensure that a particular service can communicate with its database. This is but it only controls service to service communication and not what pods can communicate within the environment.

Kubernetes Network Policy

In order to achieve micro segmentation for kubernetes workloads we need to leverage kubernetes network policies or a similar construct to ensure we’ve restricted ingress and egress traffic from the pod to only what is absolutely necessary. This helps ensure that all our kubernetes pods are able to communicate with the oracle production database that’s running on bare metal hardware.

VM/Bare Metal Host Firewall

The ability to do this has been available for years with host based firewalls like the windows firewall and IP Tables for linux along with third party host firewalls. The challenge has always been the willingness to manage the necessary rules. Public cloud has made this much more appealing with security groups along with network policies in Kubernetes.

Configuration Management’s Role

Managing host firewall rules at some level of scale is nearly impossible without some management tool. Configuration management tools can be used to define the appropriate firewall rules in a manner similar to kubernetes network policies and lock down east-west traffic in an environment.

The use of configuration management to help bridge kubernetes and non-kubernetes services makes the adoption of kubernetes in a hybrid world much easier.

Puppet Bolt Dynamic Inventory for Azure

Martez Reed — Fri, 04 Sep 2020 13:00:08 +0000

Microsoft Azure Logo

Public cloud workloads are often very dynamic in nature and sometimes there isn’t a master list of all the instances that have been provisioned. There are times that you need to run a command against all the workloads or a subset of workloads based upon some node metadata such as an instance or virtual machine tag. In this blog post we’ll take a look at how Puppet Bolt integrates with Microsoft Azure.

Puppet Bolt includes an Azure inventory plugin that enables the dynamic discovery of workloads in an Azure environment. The following virtual machine attributes can be used for targeting or classifying virtual machines.

resource group
scale set
location
tags

Bolt will only target virtual machines and virtual machine scale sets that have a public IP address. The uri of the target will be set to the public IP address and the name will be set to either the fully qualified domain name if one exists or the instance name otherwise.

Generate Azure Credentials

The first thing we need to do is to generate Azure credentials for Puppet Bolt to use when searching for virtual machines. The following command generates the necessary credentials assuming you are logged into Azure.

az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"

The Azure credentials should be displayed on the screen similar to those displayed below.

Safe guard the generated credentials, they should not be shared.

{
  "client_id": "b27e2468-e9ad-5ea8-c043-196fc8d2q1mw",
  "client_secret": "91f28cwg-49e3-1qr2-825a-42fne279fd01",
  "tenant_id": "tg4b7md3-630k-8664-2t45-d1w923dww21w"
}

Inventory File

Now that we’ve got our Azure credentials we’re ready to create our Bolt inventory file. In this example we’re specifying the Azure location and the Azure resource group for our azure-vms Bolt inventory group.

# inventory.yaml
version: 2
groups:
  - name: azure-vms
    targets:
      - _plugin: azure_inventory
        tenant_id: tg4b7md3-630k-8664-2t45-d1w923dww21w
        client_id: b27e2468-e9ad-5ea8-c043-196fc8d2q1mw
        client_secret: 91f28cwg-49e3-1qr2-825a-42fne279fd01
        subscription_id: 9a656783-3215-4627-b1e2-c8973fh5r21w
        location: eastus
        resource_group: bolt

Now that we’ve defined the criteria for our Bolt inventory group we can run the bolt inventory show command to list the virtual machines that Bolt found for the group or groups specified. In the example we are listing all the virtual machines from all groups.

bolt inventory show --targets all -i inventory.yaml

The command should return the names of the Azure virtual machines that were found based upon the attributes provided.

nixagent
1 target

This unlocks the ability to quickly run commands or scripts against a dynamic group of virtual machines in an Azure environment.

Puppet Azure Key Vault Integration

Martez Reed — Mon, 24 Aug 2020 14:05:03 +0000

Puppet Azure Key Vault Integration

Automation is a necessity in today’s IT landscape but with great power comes great responsibility. Properly handling sensitive data such as machine credentials, API keys and passwords isn’t always easy when developing an automated solution. One common challenge is getting a secret from secure storage to an application’s configuration file for use by the application.

Azure helps simplify this process for Azure virtual machines with the use of Azure Key Vault and Azure Managed Identity. Azure Key Vault is a cloud service used to manage keys, secrets, and certificates. Azure Managed Identities enable a virtual machine in this case to be granted permission to the Azure Key Vault using an assigned identity.

This blog post takes a look at how Puppet can integrate with native Azure services to simplify writing a secret stored in Azure Key Vault to an application configuration file on an Azure virtual machine.

Azure Key Vault Puppet Module

The azure_key_vault forge module includes support for server side secrets retrieval using hiera and agent side retrieval using deferred functions. The module utilizes the Azure metadata service to retrieve the access credentials for interacting with Azure Key Vault to access secrets stored in Azure Key Vault.

Server side retrieval (hiera)

The module includes support for a custom hiera backend. This enables puppet code to retrieve sensitive data from Azure Key Vault during a hiera lookup. The Puppet master fetches the sensitive data from the Azure Key Vault and sends the unencrypted data to agent over the secure agent communication channel. The focus of this post is on the agent side retrieval and additional information about the server side retrieval can be found in the module’s documentation.

Agent side retrieval (deferred function)

Puppet 6 includes what are known as deferred functions, these enable functions to run on the agent node as part of a Puppet run. Utilizing deferred functions has a number of advantages over server side retrieval with hiera. One of the biggest advantages is that the sensitive data doesn’t need to be decrypted on the master and then delivered to the agent node.

Azure Key Vault Integration

Now that we understand how we deferred functions work and what the azure_key_vault module supports, we’ll look at an example of the integration.

The example is an application configuration file dynamically populated using Puppet with the password being fetched from Azure Key Vault by the agent node.

Azure Authentication

The agent node virtual machine is expected to be running on Azure and use a managed system identity or a user assigned identity with the appropriate permissions to access the Azure key vault.

Demo App Module

In our demo application Puppet module we need to create an init.pp manifest and a config.yaml.epp template file in module’s files directory.

The following example highlights the Azure Key Vault integration to populate the password in a configuration file. The example uses Puppet’s EPP templating to dynamically create and populate the file content.

---
host: <%= $host %>
password: <%= $admin_password_secret.unwrap %>

The template file is placed in the module’s files directory instead of the templates directory since the template file must be present on the agent node for the deferred rendering. https://puppet.com/docs/puppet/6.17/template_with_deferred_values.html

The following manifest shows how the password is being set by a value retrieved from Azure Key Vault.

class demoapp (
  String $key_vault_name = 'grtdevvault',
  String $key_vault_secret_name = 'app-password',
  String $host = 'grtapp01.grt.local',
) {

$password = Deferred('azure_key_vault::secret',
                ["$key_vault_name","$key_vault_secret_name",{"metadata_api_version"=>"2018-04-02","vault_api_version"=>"2016-10-01"}])

$hash_variables = {
    'admin_password_secret' => $password,
    'host' => $host,
  }

file { '/opt/demoapp':
    ensure => directory,
  }

file { '/opt/demoapp/config.yaml':
    ensure => file,
    content => Deferred('inline_epp',
                [file('demoapp/config.yaml.epp'), $hash_variables]),
  }
}

Now that our Puppet code has been added, the next Puppet agent run will write the file to the agent node’s filesystem with the unencrypted version of the password in the config.yaml file for use by the application similar to that shown below.

---
host: grtapp01.grt.local
password: Secret12345

This blog post covered a simple and powerful use case for ensuring that sensitive data such as passwords are being stored and handled in a secure manner.

References

Puppet EPP Templates with deferred functions

https://puppet.com/docs/puppet/6.17/template_with_deferred_values.html

Azure virtual machine managed identity

https://docs.microsoft.com/en-us/azure/key-vault/general/tutorial-python-virtual-machine

Deploying Puppet Enterprise Agents with HashiCorp Terraform on Azure VMs

Martez Reed — Tue, 18 Aug 2020 15:28:16 +0000

Microsoft Azure Logo

HashiCorp Terraform is an open source Infrastructure as Code (IaC) tool that is widely used to deploy cloud infrastructure in the public cloud such as AWS and Azure along with on-premises VMware vSphere environments.

One of the challenges is developing a method for bootstrapping the instances with configuration management agents such as the Puppet Enterprise agent. In this blog post we cover a simple and easy way to install the Puppet Enterprise agent on Azure virtual machines provisioned with HashiCorp Terraform.

Azure Virtual Machine Extensions

Microsoft Azure supports what are known as virtual machine extensions which small applications that provide post-deployment configuration and automation on Azure VMs. There are a number of extensions available from companies such as DataDog, New Relic and others. These extensions have been created to wrap the installation and configuration of their respective agents.

Custom Script Extension

In addition to extensions created by vendors, Microsoft Azure has created a custom script extensions that allows arbitrary commands or scripts to be executed during the post-provisioning stage. The HashiCorp Terraform Azure provider includes a resource for custom script extensions and can be used to quickly install the Puppet Enterprise agent on a virtual machine during the provisioning process.

Puppet Enterprise Agent Installation

Puppet Enterprise provides a simple method for installing the Puppet Enterprise agent using the PE agent install script. Using this script enables us to easily provide additional agent configuration information such as trusted facts that are embedded in the CSR or a pre-shared key used for automatically signing the agent SSL certificate. This method assumes that a certificate autosiging process is in place to allow the certificate to be automatically signed during the bootstrap process.

If sensitive information such as the pre-shared key is passed as part of the provisioning code it should be properly secured. There are several options to properly secure that information.

Create a custom wrapper script that dynamically fetches the sensitive information from Azure Key Vault
Create a custom wrapper script that dynamically fetches the sensitive information from a HashiCorp Vault deployment
Embed the sensitive information in a custom wrapper script that is securely stored in an Azure Blob

Linux

The Puppet Enterprise agent installation script for Linux uses Bash and an example is show below:

The hostname should be replaced with the FQDN of your Puppet Enterprise master or compiler load balancer

curl -k https://puppetmaster.grt.local:8140/packages/current/install.bash] | sudo bash -s custom_attributes:challengePassword=PASSWORD123 extension_requests:pp_role=web

Once we’ve got our installation command we just need to add it to an azurerm_virtual_machine_extension Terraform resource.

resource "azurerm_virtual_machine_extension" "linux_pe_install" {
  name ="PEAgentInstallLinux"
  virtual_machine_id = azurerm_linux_virtual_machine.example.id
  publisher ="Microsoft.Azure.Extensions"
  type ="CustomScript"
  type_handler_version ="2.0"

  settings =  << SETTINGS
    {
        "commandToExecute": "curl -k https://puppetmaster.grt.local:8140/packages/current/install.bash | sudo bash -s custom_attributes:challengePassword=PASSWORD123 extension_requests:pp_role=web"
    }
SETTINGS

  tags ={
    environment ="Production"
  }
}

Windows

The Puppet Enterprise agent installation script for Windows uses PowerShell and an example is show below:

The hostname should be replaced with the FQDN of your Puppet Enterprise master or compiler load balancer

[System.Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; [Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $webClient = New-Object System.Net.WebClient; $webClient.DownloadFile('https://puppetmaster.grt.local:8140/packages/current/install.ps1', 'install.ps1'); .\install.ps1 custom_attributes:challengePassword=PASSWORD123 extension_requests:pp_role=database

Once we’ve got our installation command we just need to add it to an azurerm_virtual_machine_extension Terraform resource.

resource "azurerm_virtual_machine_extension" "windows_pe_install" {
  name ="PEAgentInstallWindows"
  virtual_machine_id = azurerm_windows_virtual_machine.example.id
  publisher ="Microsoft.Azure.Extensions"
  type ="CustomScript"
  type_handler_version ="2.0"

  settings =  << SETTINGS
    {
        "commandToExecute": "[System.Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; [Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $webClient = New-Object System.Net.WebClient; $webClient.DownloadFile('https://puppetmaster.grt.local:8140/packages/current/install.ps1', 'install.ps1'); .\install.ps1 custom_attributes:challengePassword=PASSWORD123 extension_requests:pp_role=database"
    }
SETTINGS

  tags = {
    environment ="Production"
  }
}

There are certainly more complex or intricate configurations that can be developed to install the Puppet Enterprise agent. This post focused on providing a simple method to easily get started with deploying Puppet Enterprise agents with HashiCorp Terraform.

References

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/overview

https://www.terraform.io/docs/providers/azurerm/r/virtual_machine_extension.html

Creating Azure VM Images With Packer and Puppet Bolt

Martez Reed — Tue, 11 Aug 2020 14:36:38 +0000

Microsoft Azure Logo

HashiCorp Packer is a free and open source tool for creating golden images for multiple platforms from a single source configuration. Packer makes it easy to codify VM images for Microsoft Azure.

In this blog post we’ll look at how to use HashiCorp Packer and Puppet Bolt to define our VM templates in code.

Puppet Bolt Packer Plugin

HashiCorp Packer doesn’t natively integrate with Puppet Bolt. A Packer plugin has been created to simplify this integration. To begin using the plugin, the latest release bundle for your operating system should be downloaded from the https://github.com/martezr/packer-provisioner-puppet-bolt/releases/latest Github repository and unpacked.

Once the packer-provisioner-puppet-bolt binary has been unpacked, it should be moved to a path on the system where Packer can find it as covered in the link below.

https://www.packer.io/docs/extending/plugins#installing-plugins

Puppet Bolt Plan

Ensure that the latest version of Puppet Bolt is installed before getting started.

In this post we’ll be using Puppet Bolt to install NGINX as a simple example of the integration between Packer and Bolt. The Bolt YAML plan below installs the epel-release repository, nginx and enables the service to start at boot.

parameters:
  targets:
    type: TargetSpec

steps:
  - command: yum -y install epel-release
    targets: $targets
    description: "Install epel-release"
  - command: yum -y install nginx
    targets: $targets
    description: "Install nginx"
  - command: systemctl enable nginx
    targets: $targets
    description: "Start nginx on boot"

Packer Template

We now need to create our Packer template that defines the settings for our VM image such as the operating system and hardware configuration. Before we create our template we’ll generate our Azure credentials if we don’t already have credentials and create a dedicated resource group for the VM image generated by Packer.

Create a new Azure resource group for the VM image or using an existing resource group. We’ll specify a resource group in our Packer template later on.

az group create -n packerbolt -l centralus

We need to generate Azure credentials for Packer to use when building the VM image. The following command generates the necessary credentials assuming you are logged into Azure.

az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"

The Azure credentials should be displayed on the screen similar to those displayed below.

Safe guard the generated credentials, they should not be shared.

{
  "client_id": "b27e2468-e9ad-5ea8-c043-196fc8d2q1mw",
  "client_secret": "91f28cwg-49e3-1qr2-825a-42fne279fd01",
  "tenant_id": "tg4b7md3-630k-8664-2t45-d1w923dww21w"
}

We can pass the credentials at the command line, include them in a variables file or add them as environment variables as seen below.

export ARM_CLIENT_ID="b27e2468-e9ad-5ea8-c043-196fc8d2q1mw"
export ARM_CLIENT_SECRET="91f28cwg-49e3-1qr2-825a-42fne279fd01"
export ARM_TENANT_ID="tg4b7md3-630k-8664-2t45-d1w923dww21w"

With the Azure credentials set we can now create our Packer template file to define our VM image. The managed_image_resource_group_name field is set to the Azure resource group we created earlier.

{
  "variables": {
    "client_id": "{{env `ARM_CLIENT_ID`}}",
    "client_secret": "{{env `ARM_CLIENT_SECRET`}}",
    "subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
    "tenant_id": "{{env `ARM_TENANT_ID`}}",
    "ssh_user": "centos",
    "ssh_pass": "{{env `ARM_SSH_PASS`}}"
  },
  "builders": [{
    "type": "azure-arm",

    "client_id": "{{user `client_id`}}",
    "client_secret": "{{user `client_secret`}}",
    "subscription_id": "{{user `subscription_id`}}",
    "tenant_id": "{{user `tenant_id`}}",

    "managed_image_resource_group_name": "packerbolt",
    "managed_image_name": "MyCentOSImage",

    "ssh_username": "{{user `ssh_user`}}",
    "ssh_password": "{{user `ssh_pass`}}",

    "os_type": "Linux",
    "image_publisher": "OpenLogic",
    "image_offer": "CentOS",
    "image_sku": "8_2",
    "image_version": "latest",
    "ssh_pty": "true",

    "location": "Central US",
    "vm_size": "Standard_B1MS"
  }],
  "provisioners": [
    {
      "type": "puppet-bolt",
      "user": "centos",
      "run_as": "root",
      "bolt_module_path": "/Users/martez.reed/Documents/GitHub/puppet-on-azure/Bolt",
      "bolt_plan": "azure::web",
      "bolt_params": {}
    },
    {
      "execute_command": "echo '{{user `ssh_pass`}}' | {{ .Vars }} sudo -S -E sh '{{ .Path }}'",
      "inline": [
        "yum update -y",
        "/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync"
      ],
      "inline_shebang": "/bin/sh -x",
      "type": "shell",
      "skip_clean": true
    }
]
}

The Puppet Bolt provisioner section from the full template above shows that we’ve specified a few settings for our Puppet Bolt provisioner. We specified a Bolt plan, a path for where to look for our modules and authentication along with privilege escalation information.

{
  "type": "puppet-bolt",
  "user": "centos",
  "run_as": "root",
  "bolt_module_path": "./puppet-on-azure/Bolt",
  "bolt_plan": "azure::web",
  "bolt_params": {}
}

With the Packer template created we can now build our Azure image by running the packer build command and provide the name of the template file.

packer build centos8.json

The build will take a few minutes and should display output similar to that shown below:

azure-arm: output will be in this color.

==> azure-arm: Running builder ...
==> azure-arm: Getting tokens using client secret
==> azure-arm: Getting tokens using client secret
    azure-arm: Creating Azure Resource Manager (ARM) client ...
==> azure-arm: WARNING: Zone resiliency may not be supported in Central US, checkout the docs at [https://docs.microsoft.com/en-us/azure/availability-zones/](https://docs.microsoft.com/en-us/azure/availability-zones/)
==> azure-arm: Creating resource group ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> Location : 'Central US'
==> azure-arm: -> Tags :
==> azure-arm: Validating deployment template ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> DeploymentName : 'pkrdprivksir0po'
==> azure-arm: Deploying deployment template ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> DeploymentName : 'pkrdprivksir0po'
==> azure-arm: Getting the VM's IP address ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> PublicIPAddressName : 'pkriprivksir0po'
==> azure-arm: -> NicName : 'pkrnirivksir0po'
==> azure-arm: -> Network Connection : 'PublicEndpoint'
==> azure-arm: -> IP Address : '23.101.127.134'
==> azure-arm: Waiting for SSH to become available...
==> azure-arm: Connected to SSH!
==> azure-arm: Provisioning with Puppet Bolt...
==> azure-arm: Executing Bolt: bolt plan run azure::web --params {} --modulepath /Users/martez.reed/Documents/GitHub/puppet-on-azure/Bolt --targets ssh://127.0.0.1:65059 --user centos --no-host-key-check --private-key /var/folders/ly/bwpnd5gn5tv7549rgn80x4jw0000z_/T/packer-provisioner-bolt.164237326.key --run-as root
    azure-arm: Starting: plan azure::web
    azure-arm: Starting: Install epel-release on ssh://127.0.0.1:65059
    azure-arm: Finished: Install epel-release with 0 failures in 11.75 sec
    azure-arm: Starting: Install nginx on ssh://127.0.0.1:65059
    azure-arm: Finished: Install nginx with 0 failures in 17.38 sec
    azure-arm: Finished: plan azure::web in 29.15 sec
    azure-arm: Plan completed successfully with no result
==> azure-arm: Provisioning with shell script: /var/folders/ly/bwpnd5gn5tv7549rgn80x4jw0000z_/T/packer-shell758099055
==> azure-arm: Querying the machine's properties ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> ComputeName : 'pkrvmrivksir0po'
==> azure-arm: -> Managed OS Disk : '/subscriptions/2a646183-6919-4320-a1f3-c6985fc5d87e/resourceGroups/PKR-RESOURCE-GROUP-RIVKSIR0PO/providers/Microsoft.Compute/disks/pkrosrivksir0po'
==> azure-arm: Querying the machine's additional disks properties ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> ComputeName : 'pkrvmrivksir0po'
==> azure-arm: Powering off machine ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> ComputeName : 'pkrvmrivksir0po'
==> azure-arm: Capturing image ...
==> azure-arm: -> Compute ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: -> Compute Name : 'pkrvmrivksir0po'
==> azure-arm: -> Compute Location : 'Central US'
==> azure-arm: -> Image ResourceGroupName : 'packerbolt'
==> azure-arm: -> Image Name : 'MyCentOSImage'
==> azure-arm: -> Image Location : 'Central US'
==> azure-arm: Deleting resource group ...
==> azure-arm: -> ResourceGroupName : 'pkr-Resource-Group-rivksir0po'
==> azure-arm: 
==> azure-arm: The resource group was created by Packer, deleting ...
==> azure-arm: Deleting the temporary OS disk ...
==> azure-arm: -> OS Disk : skipping, managed disk was used...
==> azure-arm: Deleting the temporary Additional disk ...
==> azure-arm: -> Additional Disk : skipping, managed disk was used...
==> azure-arm: Removing the created Deployment object: 'pkrdprivksir0po'
==> azure-arm: ERROR: -> ResourceGroupNotFound : Resource group 'pkr-Resource-Group-rivksir0po' could not be found.
==> azure-arm:
Build 'azure-arm' finished.

==> Builds finished. The artifacts of successful builds are:
--> azure-arm: Azure.ResourceManagement.VMImage:

OSType: Linux
ManagedImageResourceGroupName: packerbolt
ManagedImageName: MyCentOSImage
ManagedImageId: /subscriptions/2a646183-6919-4320-a1f3-c6985fc5d87e/resourceGroups/packerbolt/providers/Microsoft.Compute/images/MyCentOSImage
ManagedImageLocation: Central US

The Puppet Bolt plan can be much more complex but the goal of this post was to showcase how easy it is to integrate the two together.