The Cornerstone Collection is a lab provisioning tool built on Red Hat Ansible Automation Platform. It streamlines the process of creating virtual machines (VMs) across on-premises environments (libvirt) and cloud-based platforms (such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)). Figure 1 depicts this. In this article, we’ll walk through a simple demonstration of how to deploy a test instance on AWS and GCP using the collection.
For those of you who are more text-based learners, you can follow this tutorial to understand how the collection works and how to raise a VM. For others that favor a more visual learning style, you can follow the tutorial in the following videos.
How does it all work?
The collection comprises of 2 roles: pre-req-install and cornerstone. Both of them leverage a global vars file called main.yml which lives in a separate directory next to the playbooks that call these roles for the provisioning process. The reason for this is that main.yml contains all the variables that are integral to building the VMs, thus increasing a need for ease of access.
Playbook ordering:
```
[oezeakac@oezeakac-thinkpadt14gen3 cornerstone-playbooks]$ tree
.
├── pre-req-run.yml
├── run.yml
└── vars
└── main.yml
```pre-req-install role:
This role automates the installation and configuration of packages and tools needed to create the virtual machines. The role is utilized via a playbook (pre-req-run.yml) as shown below and uses the main.yml vars file to complete a successful install. If you look at the main.yml excerpt below, you can see examples on what variables to provide to raise the VM in AWS or GCP.
pre-req-run.yml:
```
---
- name: Build Instance
hosts: localhost
vars_files:
- vars/main.yml
tasks:
- include_role:
name: cornerstone.cornerstone.pre_req_install
```Full examples can be found below:
/vars/main.yml (AWS):
```yaml
aws_system_user:
aws_profile: #Ex: profile1
aws_access_key: #access-key
aws_secret_key: # secret-key
aws_region: #Ex: "eu-west-1"
aws_format: #Ex: table
foundation: #Ex: "aws"
key_name: #Ex: aws_keypair
key_file: #Ex: /home/oezeakac/labs/Ansible/cornerstone-playbooks/aws_keypair #non-root dir
ansible_python_interpreter: #Ex: /usr/bin/python3.11
cornerstone_prefix: #Ex: cs
cornerstone_ssh_admin_username: #Ex: rhadmin
cornerstone_ssh_admin_pubkey: #Ex: rsa.pub
cornerstone_aws_ssh_key_name: #Ex: "{{ key_name }}"
cornerstone_aws_profile: #Ex: default
cornerstone_ssh_user: #Ex: ec2-user
cornerstone_ssh_key_path: #Ex: "ssh_key.pem"
cornerstone_platform: #Ex: aws
cornerstone_location: #Ex: eu-west-1
```/vars/main.yml (GCP):
```yaml
foundation: #Ex: "gcp"
```The foundation variable is used to determine set-up tasks that will run under the tasks folder of the role. Take a look at the main.yml file under the tasks directory. If the value of the foundation variable is set to aws then the aws.yml playbook will run and execute aws-related installation tasks. If the foundation variable is set to gcp then the gcp.yml playbook will run and execute GCP-related tasks. The same logic applies for the values Libvrt and Azure.
/tasks/main.yml:
```yaml
- name: AWS Pre-Req Install
ansible.builtin.include_tasks: "aws.yml"
when: foundation == 'aws'
- name: Azure Pre-Req Install
ansible.builtin.include_tasks: "azure.yml"
when: foundation == 'azure'
- name: Libvrt Pre-Req Install
ansible.builtin.include_tasks: "libvrt.yml"
when: foundation == 'libvrt'
- name: GCP AWS Pre-Req Install
ansible.builtin.include_tasks: "gcp.yml"
when: foundation == 'gcp'
```When ready populate the vars file with the relevant information and run the playbook with the following command:
```
ansible-navigator run pre-req-run.yml
```Cornerstone role
This role carries out the task of creating the virtual machines in their chosen cloud environments.
run.yml:
```
---
- name: Build Instance
hosts: localhost
vars_files:
- vars/main.yml
tasks:
- include_role:
name: cornerstone.cornerstone.Cornerstone
```/vars/main.yml (AWS):
```yaml
cornerstone_sg:
- name: "testworkshop-sg"
description: Security group for aws
region: "{{ cornerstone_location }}"
rules:
- proto: tcp
from_port: 22
to_port: 22
group_name: ""
cidr_ip: 0.0.0.0/0
rule_desc: "allowSSHin_all"
- proto: tcp
from_port: 443
to_port: 443
group_name: ""
cidr_ip: 0.0.0.0/0
rule_desc: "allowHttpsin_all"
- proto: all
from_port: ""
to_port: ""
group_name: "testworkshop-sg"
cidr_ip: 0.0.0.0/0
rule_desc: "allowAllfromSelf"
vm_state: present
guests:
testsystem1:
cornerstone_vm_state: #Ex: "{{vm_state}}"
cornerstone_platform: #Ex: aws
cornerstone_tag_purpose: #Ex: "Testing"
cornerstone_tag_role: #Ex: "testsystem"
cornerstone_vm_name: #Ex: testsystem
cornerstone_location: #Ex: eu-west-1
cornerstone_vm_aws_az: #Ex: eu-west-1a
cornerstone_vm_flavour: #Ex: t3.2xlarge
cornerstone_vm_aws_ami: #Ex: ami-0b04ce5d876a9ba29
cornerstone_vm_aws_sg: #Ex: obitestworkshop-sg
cornerstone_virtual_network_name: #Ex: "{{ cornerstone_prefix }}vnet"
cornerstone_virtual_network_cidr: #Ex: "10.1.0.0/16"
cornerstone_subnet_name: #Ex: "{{ cornerstone_prefix }}subnet"
cornerstone_public_private_ip: #Ex: public
cornerstone_vm_private_ip:
cornerstone_vm_assign_public_ip: #Ex: yes
cornerstone_vm_public_ip: #Ex: 63.34.15.95
cornerstone_publicip_allocation_method: #Ex: Dynamic
cornerstone_publicip_domain_name: #Ex: null
cornerstone_vm_os_disk_size: #Ex: 10
cornerstone_vm_data_disk: #Ex: false
cornerstone_vm_data_disk_device_name: #Ex: "/dev/xvdb"
cornerstone_aws_vm_data_disk_managed: #Ex: "gp2"
cornerstone_vm_data_disk_size: #Ex: "50"
```/vars/main.yml (GCP):
```yaml
cornerstone_prefix: #Ex: cs
cornerstone_platform: #Ex: gcp
ansible_python_interpreter: #Ex: /usr/bin/python3.11
cornerstone_gcp_project: #Ex: openenv-d2p2t
cornerstone_gcp_auth_kind: #Ex: "serviceaccount"
cornerstone_service_account_file: #Ex: /home/oezeakac/labs/Ansible/cornerstone-playbooks/openenv-prbtd-6d274028b755.json - This is the private key
cornerstone_virtual_network_name: #Ex: "{{ cornerstone_prefix }}-vnet"
cornerstone_location: #Ex: europe-west2
cornerstone_gcp_zone: #Ex: europe-west2-a
cornerstone_virtual_network_cidr: #Ex: 172.16.0.0/28
cornerstone_gcp_use_serviceaccount: true
cornerstone_ssh_admin_username: root user
cornerstone_ssh_admin_pubkey: #<generate pub ssh key and sub in here when running run.yml>
ocp4_platform: gcp
cornerstone_sg:
- name: "cs-sg"
description: "firewall rules"
rules:
- proto: tcp
from_port: 22
vm_state: present
guests:
bastion:
cornerstone_platform: #Ex: gcp
cornerstone_gcp_project: #Ex: openenv-d2p2t
cornerstone_gcp_auth_kind: #Ex: "serviceaccount"
cornerstone_service_account_file: "" #Ex:/home/oezeakac/labs/Ansible/cornerstone-playbooks/openenv-prbtd-6d274028b755.json
cornerstone_working_dir: #Ex:'/tmp/'
cornerstone_vm_state: #Ex:"{{vm_state}}"
cornerstone_vm_name: #Ex: "bastion"
cornerstone_location: #Ex: europe-west2
cornerstone_gcp_zone: #Ex: europe-west2-a
cornerstone_virtual_network_name: #Ex: "{{ cornerstone_prefix }}-vnet"
cornerstone_virtual_network_cidr: #Ex: 172.16.0.0/28
cornerstone_subnet_name: #Ex: "{{ cornerstone_prefix }}subnet"
cornerstone_vm_flavour: #Ex: e2-medium
cornerstone_vm_gcp_source_image: #Ex:"projects/rhel-cloud/global/images/rhel-8-v20230411"
cornerstone_vm_os_disk_size: #Ex: 30
cornerstone_tag_purpose: #Ex: "bastion"
cornerstone_tag_role: #Ex: "testing"
```Like the previous role, cornerstone is used via a playbook which leverages the role and main.yml in the vars directory. If you look back at the example vars file above, you can see it contains the configuration information to create the virtual machine in your chosen cloud platform. So if you’ve chosen AWS, things such as VPC, security groups, EC2 flavor, and etc. are all detailed here. The cornerstone-platform variable determines the type of tasks that need to be run to complete provisioning. Under the tasks folder the main.yml checks the value of cornerstone-platform and if it’s set to e.g., aws, all the task files that are AWS-specific are run. The same goes for GCP if the value of the variable is set to gcp.
Run the playbook using the command below:
```
ansible-navigator run run.yml
```Once that’s complete you can head to the AWS console and check under the EC2 Dashboard to confirm that a test instance has been created. See Figure 2.
For the bastion server in GCP, if you log into the console you can see that’s been generated (Figure 3).
