AI for DevOps Engineers - Part 1: The Building Blocks of DevOps AI
DevOps is a key success factor for modern software development and we have most definitely come across AI in one way or another. The intersection of AI and
Within all the cloud providers you get automated built template based virtual machines - what about doing this on your own to build your custom Templates for VMWare vSphere? In this case HashiCorp Packer is the tool you want to go for. This posting will go through the main concepts of creating a packer based virtual machine template
Packer images allow you to launch completely provisioned and configured machines in seconds, rather than several minutes or hours. This benefits not only production, but development as well, since development virtual machines can also be launched in seconds, without waiting for a typically much longer provisioning time.
Because Packer creates identical images for multiple platforms, you can run production in AWS, staging/QA in a private cloud like OpenStack, and development in desktop virtualization solutions such as VMware or VirtualBox. Each environment is running an identical machine image, giving ultimate portability.
Packer installs and configures all the software for a machine at the time the image is built. If there are bugs in these scripts, they'll be caught early, rather than several minutes after a machine is launched.
After a machine image is built, that machine image can be quickly launched and smoke tested to verify that things appear to be working. If they are, you can be confident that any other machines launched from that image will function properly.
Packer makes it extremely easy to take advantage of all these benefits.
To start with Packer download the prebuilt binary. After installing Packer, verify the installation worked by opening a new command prompt or console, and checking that packer is available:
1$ packer
2usage: packer [--version] [--help] <command> [<args>]
3
4Available commands are:
5 build build image(s) from template
6 fix fixes templates from old versions of packer
7 inspect see components of a template
8 validate check that a template is valid
9 version Prints the Packer version
To use the upper template with VMWare ESXi 6 and later you must perform some modifications on the ESXi host. The ESXi host needs a little bit of configuration to allow Packer to work. Packer communicates over SSH, so first we need to open that. Secondly, we’ll enable an option to discover Guest IPs from the Host and then finally allow VNC connections remotely.
Inside the web UI, navigate to “Manage”, then the “Services” tab. Find the entry called: “TSM-SSH”, and enable it. You may wish to enable it to start up with the host by default. You can do this inside the “Actions” dropdown (it’s nested inside “Policy”).
Run the following command on the ESXi host:
1esxcli system settings advanced set -o /Net/GuestIPHack -i 1
This allows Packer to infer the guest IP from ESXi, without the VM needing to report it itself.
Packer connects to the VM using VNC, so we’ll open a range of ports to allow it to connect to it.
First, ensure we can edit the firewall configuration:
1chmod 644 /etc/vmware/firewall/service.xml
2chmod +t /etc/vmware/firewall/service.xml
Then append the range we want to open to the end of the file:
1<service id="1000">
2 <id>packer-vnc</id>
3 <rule id="0000">
4 <direction>inbound</direction>
5 <protocol>tcp</protocol>
6 <porttype>dst</porttype>
7 <port>
8 <begin>5900</begin>
9 <end>6000</end>
10 </port>
11 </rule>
12 <enabled>true</enabled>
13 <required>true</required>
14</service>
Finally, restore the permissions and reload the firewall:
1chmod 444 /etc/vmware/firewall/service.xml
2esxcli network firewall refresh
The configuration file used to define what image we want built and how is called a template in Packer terminology. The format of a template is simple JSON. JSON struck the best balance between human-editable and machine-editable, allowing both hand-made templates as well as machine generated templates to easily be made.
We'll start by creating the entire template, then we'll go over each section briefly. Create a file example.json and fill it with the following contents:
1{% raw %}
2{
3 "builders": [{
4 "name": "Ubuntu-19.04",
5 "type": "vmware-iso",
6 "vm_name": "Ubuntu-19.04",
7 "guest_os_type": "ubuntu-64",
8 "tools_upload_flavor": "linux",
9 "headless": true,
10
11 "iso_urls": ["iso/ubuntu-19.04-server-amd64.iso",
12 "http://cdimage.ubuntu.com/ubuntu/releases/19.04/release/ubuntu-19.04-server-amd64.iso"
13 ],
14 "iso_checksum": "7e8a0d07522f591dfee9bc9fcd7c05466763161e6cb0117906655bce1750b2fa",
15 "iso_checksum_type": "sha256",
16
17 "cpus": 2,
18 "memory": 4096,
19 "disk_size": 20140,
20
21 "boot_wait": "10s",
22 "boot_command": [
23 "<esc><wait>",
24 "<esc><wait>",
25 "<enter><wait>",
26 "/install/vmlinuz",
27 " initrd=/install/initrd.gz ",
28 "auto=true ",
29 "url=https://raw.githubusercontent.com/infralovers/packer-preseed/master/ubuntu.cfg ",
30 "fb=false ",
31 "auto=true ",
32 "language=en ",
33 "locale=en_US ",
34 "priority=critical ",
35 "keymap=us ",
36 "netcfg/get_hostname={{ .Name }} ",
37 "netcfg/get_domain=vm ",
38 "debconf/frontend=noninteractive ",
39 "debian-installer/country=AT ",
40 "console-setup/ask_detect=false ",
41 "console-keymaps-at/keymap=us ",
42 "DEBCONF_DEBUG=5 ",
43 "<enter>"
44 ],
45
46 "ssh_username": "vagrant",
47 "ssh_password": "vagrant",
48 "ssh_port": 22,
49 "ssh_wait_timeout": "20m",
50 "shutdown_command": "echo 'shutdown -P now' > shutdown.sh; echo 'vargant'|sudo -S sh 'shutdown.sh'",
51
52 "vnc_disable_password": true,
53 "format": "vmx",
54 "remote_type": "esx5",
55 "remote_host": "{{user `esxi_host`}}",
56 "remote_datastore": "{{user `esxi_datastore`}}",
57 "remote_username": "{{user `esxi_username`}}",
58 "remote_password": "{{user `esxi_password`}}",
59 "keep_registered": true,
60 "skip_export": true
61
62 }]
63}
64{% endraw %}
You can also start building images with VMWare Fusion when you remove the remote_* keys in the json. When doing the initial work this can be quite useful to keep the loop tight, because debugging debconf or kickstart files is easier going the local devloop In the Ubuntu based example the bootswitch DEBCONF_DEBUG is used to output on the installation log when a settings is found that is not set or set to an invalid value.
With a properly validated template, it is time to build your first image. This is done by calling packer build with the template file. The output should look similar to below. Note that this process typically takes a few minutes. Because the template uses variables for the esxi specific data, these must be set on build time with the -var argument.
1packer build -var "esxi_host=YOUR-ESXI" -var "esxi_datastore=YOUR_DEFAULT_DATASTORE" -var "esxi_username=ESXI_USERNAME" -var "esxi_password=ESXI_PASSWORD" ubuntu.json
The upper command would just generate a default installed Ubuntu 19.04 image using a preseed file which just generates a user who is able to use sudo.
So the next step in this setup is to do some custom provisioning. For this packer is able to launch provisioners. Using these methods you are able to:
The full template will like this:
1{% raw %}
2{
3 "builders": [{
4 ...
5 }],
6 "provisioners": [{
7 "type": "shell",
8 "execute_command": "echo 'vagrant' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
9 "script": "scripts/setup.sh"
10 },
11 {
12 "type": "ansible-local",
13 "playbook_dir": "ansible",
14 "playbook_file": "ansible/main.yml",
15 "extra_arguments": ["--extra-vars \"root_password={{user `root_password`}} user_password={{user `user_password`}}\""]
16 },
17 {
18 "type": "shell",
19 "execute_command": "echo 'vagrant' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
20 "script": "scripts/cleanup.sh"
21 }
22 ]
23}
24{% endraw %}
The layout of the local is like
1|-- ansible
2| |-- ansible.cfg
3| |-- main.yml
4| |-- roles
5|-- scripts
6|-- ubuntu.json
7`-- variables.json
Within ansible/main.yml you can define your playbook to install default tools and libraries ( e.g. cloud-init ) and set custom configuration items.
When running the upper build process the result is a customized VMWare machine, which is ready to run - but we wanted to get a VMWare template to produce virtual machines with this build. For this Packer has Post Processors in place. In our use case we gonna use the vsphere post processor and also the vsphere-template processor which finally generates our template. The vsphere post processor halts the previous generated virtual machine and tranfers it to the specified directory. Afterwards the vsphere template post processesor transforms the virtual machine into a machine template for later usage.
1{% raw %}
2{
3 "builders": [{
4 ...
5 }],
6 "provisioners": [{
7 }],
8 "post-processors": [
9 [{
10 "type": "vsphere",
11 "cluster": "{{user `esxi_vsphere_cluster`}}",
12 "host": "{{user `esxi_vsphere_host`}}",
13 "datacenter": "{{user `esxi_vsphere_dc`}}",
14 "username": "{{user `esxi_vsphere_username`}}",
15 "password": "{{user `esxi_password`}}",
16 "datastore": "{{user `esxi_datastore`}}",
17 "vm_name": "T_Ubuntu",
18 "vm_network": "VM Network",
19 "vm_folder": "/Templates",
20 "disk_mode": "thin",
21 "insecure": "true",
22 "overwrite": "true"
23 },
24 {
25 "type": "vsphere-template",
26 "host": "{{user `esxi_vsphere_host`}}",
27 "insecure": "true",
28 "datacenter": "{{user `esxi_vsphere_dc`}}",
29 "username": "{{user `esxi_vsphere_username`}}",
30 "password": "{{user `esxi_password`}}",
31 "folder": "/Templates"
32 }
33 ]
34 ]
35}
36{% endraw %}
You are interested in our courses or you simply have a question that needs answering? You can contact us at anytime! We will do our best to answer all your questions.
Contact us