I recently took a position at a new company and had the opportunity to stand up a greenfield environment. Part of this environment was obviously configuring monitoring. Since we’re pretty heavily tied to VMware here, we’re using vROps for our monitoring. For escalation of alerts, we’re using OpsGenie, and for normal collaboration we’re using Teams. Unfortunately, vROps versions older than 8.4 do not support sending alerts to OpsGenie or Teams out of the box. Fortunately, we can still get this working with a bit of work.

Overview

Approach

We’ll be running this whole project using Photon OS 4.

While we could simply run the python script in a screen, tmux, or similar session, but there are serious limitations in doing that. Admittedly, my python isn’t as strong as some of my other scripting languages, but after a bit of digging, it became clear that things like security, performance, and monitoring are either limited or unavailable if we do this. We’ll use a WSGI server called Gunicorn to run the python script, and use systemd to create a socket and service, and finally, use Nginx to connect directly to the socket. Whew! Even just reading that after completing this entire project feels like a lot, but don’t worry. As always, I’ll explain each step in detail and give you code to create this project.

Create Photon Packer Template

If you don’t know this about me by now, I’m a huge fan of packer. As such, we’ll be using it to create a template. You can find the source code for this packer template on my website’s github repository

To get a local copy, run the following command:

git clone https://github.com/jonhowe/Virtjunkie.com.git

You can find all source code in the directory Virtjunkie.com/Packer/PhotonOS4.

Create Custom ISO

Unfortunately, Photon OS, even in v4, doesn’t support providing the kickstart file via CD-ROM or floppy (see Issue#1113, Issue#798). Unfortunately, this means that if we want (or need) to use the vsphere-iso builder, we’ll need to create an ISO with the kickstart file embedded. I’m not going to duplicate documentation, so here’s the official documentation from VMware on how to add a kickstart file.

Instead of using the sample my_ks.cfg file provided in the ISO, use the version below.

IMPORTANT: Ensure that you replace [yourpassword] with your actual password

Use Packer To Create vSphere Template

IMPORTANT: Ensure that the password assigned to “root_password” in Virtjunkie.com/Packer/PhotonOS4/packer-photon.json.pkr.hcl matches what is set in the kickstart file above

packer build -var-file=nable.auto.pkrvars.hcl -var-file=vars iso-local-4.0GA.json -only=vsphere-iso.vmware-template packer-photon.json.pkr.hcl

Deploy Photon 4 VM

For production systems, I typically use Terraform to deploy my VMs, and that’s what I did. I’m not going to go over that, as I’ve done it before. If nothing else, just deploy the VM from a template, assign it a static IP in the guest customization specification, and then log in using credentials set in the kickstart file.

Configure Server

Install Packages

Execute the commands below to install required packages, and to clone the repository

Configure Shims

There’s a bit of config we’ll need to do in order to make this production ready.

Configure Teams

A fellow VMware vExpert, Shane Moore has an excellent article. So that I don’t recreate the wheel, please see his instructions for how to prep your environment to use Microsoft Teams.

In short, you’ll create a webhook connector in the Microsoft Teams channel, and plug the URL that you get from Teams into the teams shim file.

Configure OpsGenie

OpsGenie is pretty simple. All we’ll need to do is create an integration by selecting your team in Opsgenie, navigating to Integrations, then selecting Add Integration.

In the resulting list of available integrations, select API.

Then note the API key (you can grab it later, it doesn’t disappear when you navigate away). We’ll use that when we configure outbound settings in vROps to use OpsGenie.

Disable Unused Shims

In my environment, I’m only going to be using Teams and OpsGenie alerts. To reduce bloat and access points that could cause me security issues, I’m disabling all shims not in use.

Edit the file loginsightwebhookdemo/webhook-shims/loginsightwebhookdemo/__init__.py

Disable Welcome Page

This could probably be optional, but I appreciate not having a welcome/hello world webpage open for a production service. We’ll disable it.

Edit the file loginsightwebhookdemo/webhook-shims/loginsightwebhookdemo/__init__.py

Configure Systemd

Create two files: /etc/systemd/system/gunicorn.service and /etc/systemd/system/gunicorn.socket and populate with the text below.

/etc/systemd/system/gunicorn.service

This service file ensures that Gunicorn is started the same way, and is managed by systemd. You’ll note that it requires gunicorn.socket, which we will create later.

/etc/systemd/system/gunicorn.socket

This socket file sets permissions for the socket assigned to gunicorn

Configure Nginx

Replace the file /etc/nginx/nginx.conf with the contents below

This is telling Nginx to connect directly to the socket we’re creating with the systemd socket gunicorn.socket we created earlier.

Enable and Start All Services

Finally, enable, and start both services, and restart Nginx

systemctl enable gunicorn.socket
systemctl enable gunicorn.service
systemctl restart gunicorn.socket 
systemctl restart gunicorn.service
systemctl restart nginx.service

Configure vRealize Operations Manager

At this point, all we need to do is configure an outbound instance for Microsoft Teams and OpsGenie.

Add a New Rest Notification Plugin

OpsGenie

To do this, sign into vROps, and navigate to Administration ->Management->Outbound Settings, or https://[Your_vROps_URL]/ui/index.action#/administration/outbound-alert-settings

After you select the Rest Notification Plugin, there are 3 fields required in the Add/Edit Outbound Instance box

Finally, navigate to Alerts -> Configuration -> Notification (https://[Your_vROps_URL]/ui/index.action#/alerts/notifications) and add a new rule that targets the adapter you just created.

Teams

Again, I’m not in the business of recreating the wheel, so check out Shane’s blog for info on how to do this.

References

The post Configure vROps To Send Alerts to OpsGenie and Microsoft Teams appeared first on VirtJunkie.

Introduction to Terraform Modules

In Part 1 of this series I compared traditional programming languages to Terraform. We can do the same thing with Modules. For example, with Powershell or Python, you can download a module that provides functionality and consume that functionality in your code without having to author it. The same thing happens in Terraform, and just like with other languages, you can create your own, or download one from a third party.

Terraform Registry

Thankfully, Hashicorp provides us with a registry that we can use to find and consume Terraform Modules. At the time this post is published, the Terraform Registry contains support for 63 providers and has 3454 Modules. So if you are looking for specific functionality, check there first!

Roll Your Own Module

That said, you may have a need to create your own module, or if you’re like me, want to make sure you understand how modules work before you use one that someone else created.

Best Practices

First and foremost, you’ll want to take a look at the official documentation from Hashicorp on the standard module structure. It gets pretty in-depth, but I’ll hit on a few high level important items.

• Store your module in github
• At the very least, make sure you split your variables and outputs into different TF files
• Include an examples directory and show every variation of how to call your module. For example, if you can create a linux image or a windows image, but you need to call them differently, show an example for each.
• Include a README.md file that has a description of the module, but also references your examples

Why store your module in GitHub?

Aside from the wide ranging benefits of using version control, using GitHub will allow you to call a specific version of your module.

File Structure

The following files should be in your GitHub reposity. When you run terraform init, it will be downloaded to the .terraform directory on the machine running the project.

main.tf

variables.tf

output.tf

How to use this module?

Now that we’ve created our module and have it in Github, all we need to do in order to complete our initial goal of having a three tier application is to create a single main.tf file, and call the module 3 times. Below is an example that allows us to set separate information for each of the new VMs.

References and what’s next?

What’s Next?

At this point we have shown how to create and manage images using packer, a couple of parts on how to use Terraform to deploy infrastructure, so all we have left is doing configuration of our newly created VMs.

• Use Ansible to configure our newly provisioned VMs
• Wrap the Terraform VM Deployment process, as well as the Ansible VM configuration process together into a single process you execute once
• Use Ansible to do a greenfield deployment of a vSphere environment

References

• Part 1 – Provision VMware VMs using Terraform
• Terraform Registry
• Module Structure

The post VMware Provisioning using Hashicorp Terraform – Part 2 appeared first on VirtJunkie.

Jitsi is an open source video conferencing platform that I’ve been hearing about a lot lately, and finally had a chance to look into. In this post I’ll explain how to use Terraform to provision a Jitsi instance when you need a conference and tear it down when you are done. We’ll be using Vultr and their Jitsi “application” and AWS Route 53 for DNS.

Why Am I Writing This Article, and What Does It Accomplish?

Why am I writing this article?

1. We always want to have our apps and infrastructure defined in code
2. We pay for traditional web conferencing software 24 hours a day, 7 days a week, regardless of if we are are using running a conference or not. Why don’t we spin up conference infrastructure when we need it, and tear it down when we don’t?

At a high level, this project will accomplish the following:

1. Provision a Vultr VPS that is pre-configured with Jitsi
2. Take the IP Address that Vultr assigns the VPS and use it to create an A Record in Route 53
3. Copy a script to your VPS that will be used to finish the Jitsi configuration
4. Run the script that we copied and pass a few command line arguments that are specific to our environment

Prerequisites

In addition to having Terraform downloaded and installed, we’ll need the following items:

Vultr Account + API Access

Vultr is definitely my go-to for VPS’s these days. Not only because of their price/performance/feature availability ratio, but because they provide a number of pre-configured applications that are ready, or near ready for use. Jitsi is one of these applications. If you do use Vultr, please do me a favor and use this link to sign up. I’ll get a little kickback, but you’ll get $100 USD to use on the site in your first month.

Once you have a Vultr account, you’ll need to generate and record an API key to use with Terraform. Use the steps below to generate it.

1. Log into Vultr
2. Navigate to Settings, and then API
3. Generate an API key, and copy it somewhere safe, we’ll be using it later

AWS Account + API Access

We’ll be using AWS’s Route 53 service, which is really just a fancy DNS service that’s hooked into AWS. In order to automate Route 53 with Terraform, we’ll need to enable API access.

Use this link to access the IAM Management page

1. Expand the “Access Keys” blade
2. Select “Create New Access Key
3. Save the resulting file, as we’ll use the contents later

Domain Registrar Using Custom Nameservers

In addition to the above, the domain you want to use will need to be configured to use the Route 53 Name Servers. Route 53 will provide you the nameservers when you create a zone, and you’ll simply plug those into your registrar DNS settings page. I’m not going to explain how to create a zone in Route 53, or how to configure your registrar, but if you have questions, throw them in the comments and I’ll do my best to help.

Getting Started

Run This Project

1. Grab the files below, or copy them from my Github Repository
2. Enter the directory that contains the files
3. At a minimum, modify the fields in the auto.tfvars file
   1. vultr_api_key
   1. aws_access_key
   2. aws_secret_key
   3. domain
   4. email
4. Initialize Terraform by running terraform init
5. Create a terraform plan by running terraform plan
6. Apply the configuration by running terraform apply
7. Voila! In less than 5 minutes, you’ve got a functional, secure Jitsi instance, running on a server and domain you control. Upon successful creation, you’ll see text like what we see below giving you the URL and credentials. When you are done with your conference, just run terraform destroy to stop from receiving charges on a server/service you aren’t using.

null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): |   JITSI SETUP COMPLETED!   |
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): JITSI URL: https://conference.yourdomain.com/

null_resource.jitsi_config (remote-exec): USERNAME: admin
null_resource.jitsi_config (remote-exec): PASSWORD: @#$asdfahgsd34579--23%4asdf

Code

Main.tf

This file does all of the work.

#main.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

#Conifugre the Vultr provider
provider "vultr" {
  api_key = var.vultr_api_key
  rate_limit = 700
  retry_limit = 3
}

#Configure the AWS Provider
provider "aws" {
  #profile    = "default"
  #shared_credentials_file = "/home/jhowe/storage/btsync/folders/Sync/awscredentials/credentials"
  region     = var.aws_region
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

#https://www.terraform.io/docs/providers/aws/d/route53_zone.html
data "aws_route53_zone" "selected" {
  name         = "${var.domain}."
  private_zone = false
}

#Provision Vultr Server
resource "vultr_server" "my_server" {
    plan_id = var.vultr_plan_id
    region_id = var.vultr_region
    app_id = var.vultr_app_id
    label = "${var.hostname}.${var.domain}"
    tag = var.vultr_tag
    hostname = "${var.hostname}.${var.domain}"
    enable_ipv6 = false
    auto_backup = false
    ddos_protection = false
    notify_activate = false

    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = self.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = self.main_ip
    }

    provisioner "local-exec" {
      command = "echo SSH to this server with the command: ssh root@${vultr_server.my_server.main_ip} with the password '${vultr_server.my_server.default_password}'"
    }
}

#Create the Route 53 A Record
#https://www.terraform.io/docs/providers/aws/r/route53_record.html
resource "aws_route53_record" "conference" {
  zone_id = data.aws_route53_zone.selected.zone_id
  name    = "${var.hostname}.${data.aws_route53_zone.selected.name}"
  type    = "A"
  ttl     = "300"
  records = ["${vultr_server.my_server.main_ip}"]
}

#This null resource exists to handle configuration of the Vultr VPS after Route 53
resource "null_resource" "jitsi_config" {
    
    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = vultr_server.my_server.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = vultr_server.my_server.main_ip
    }

    provisioner "file" {
        source      = "./configure_jitsi_param.sh"
        destination = "/root/configure_jitsi_param.sh"
    }

    provisioner "remote-exec" {
        inline = [
            "chmod +x /root/configure_jitsi_param.sh",
            "/root/configure_jitsi_param.sh ${var.hostname}.${var.domain} ${var.email} y"
        ]
    }
}

Variables.tf

This file defines the variables that we will use in main.tf

#variables.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

variable "vultr_api_key" {
    description = "API Key Used by Vultr (https://my.vultr.com/settings/#settingsapi)"
}

variable "vultr_region" {
    description = "Vultr Region Selection (curl https://api.vultr.com/v1/regions/availability?DCID=1)"
    default = 1
}

variable "vultr_plan_id" {
    description = "Vultr Plan for the VPS to use (curl https://api.vultr.com/v1/plans/list)"
    default = 202
}

variable "vultr_tag" {
    description = "Vultr Tag to apply to the new VPS"
    default = "jitsi-conference"
}

variable "vultr_app_id" {
    description = "Vultr App to pre-install. This should always be '47', if jitsi is being provisioned (curl https://api.vultr.com/v1/app/list)"
    default = 47
}

variable "hostname" {
    description = "Hostname to be used"
    default = "conferences"
}

variable "email" {
    description = "email to be used for let's encrypt acme config"
    default = "john.doe@email.com"
}

variable "domain" {
    description = "domain to be used"
    default = "aremyj.am"
}

variable "aws_access_key" {
    description = "AWS Access Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_secret_key" {
    description = "AWS Secret Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_region" {
    description = "AWS Region"
    default = "us-east-1"
}

[yourdomain].auto.tfvars

The auto.tfvars file provides values to the variables defined in the variables.tf file. You’ll have to create this file from scratch, and terraform best practices dictate that you exclude this file from source control. Here’s an example you can use. Modify this for your environment. The name doesn’t matter, as long as it ends with auto.tfvars.

vultr_api_key = "[fill this in]"
vultr_region = 1
vultr_plan_id = 202
vultr_app_id = 47
vultr_tag = "jitsi-conference"
hostname = "conference"
email = "your.email@address.org"
domain = "your-domain.com"
aws_region = "us-east-1"
aws_access_key = "[fill this in]"
aws_secret_key = "[fill this in]"

configure_jitsi_param.sh

Full disclosure, I did not create this script. Vultr created it, and provides it on your Jitsi VPS when you request it. Unfortunately, the version they provide is intended to be executed interactively, so I made a few very minor modifications to allow for us to run it with parameters.

#!/bin/bash
#This script was copied from /opt/vultr/configure_jitsi.sh on a Vultr VPS that has the one-click Jitsi App
#I added lines 7-9 to allow for adding parameters on the CLI and commented lines 11-13 to force the variables to be provided on the CLI
#https://www.vultr.com/docs/one-click-jitsi
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
HOSTNAME=$1
EMAIL=$2
response=$3
# User choices
#read -ep "Please specify which domain you would like to use: " HOSTNAME
#read -ep "Please enter your email address for Let's Encrypt Registration: " EMAIL
#read -r -p "Would you like to enable password authorization? [y/N] " response
case "$response" in
    [yY][eE][sS]|[yY])
        AUTH=1
        ;;
    *)
        AUTH=0
        ;;
esac


PROSODYPATH=/etc/prosody/conf.avail/${HOSTNAME}.cfg.lua
JITSIPATH=/etc/jitsi/meet/${HOSTNAME}-config.js
JICOFOPATH=/etc/jitsi/jicofo/sip-communicator.properties

# Remove and purge (Stop first and wait to avoid race condition)
purgeold() {        
        /opt/vultr/stopjitsi.sh
        sleep 5
        apt -y purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2 jitsi*
}

# Reinstall
reinstalljitsi() {
        echo "jitsi-videobridge2 jitsi-videobridge/jvb-hostname string ${HOSTNAME}" | debconf-set-selections
        echo "jitsi-meet-web-config jitsi-meet/cert-choice string Generate a new self-signed certificate (You will later get a chance to obtain a Let's encrypt certificate)" | debconf-set-selections
        apt-get -y install jitsi-meet
}

# Remove nginx defaults
wipenginx() {
        rm -f /etc/nginx/sites-enabled/default
}

# Configure Lets Encrypt
configssl(){
    systemctl restart nginx
    sed -i -e 's/echo.*Enter your email and press.*/EMAIL=$1/' /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    sed -i -e 's/read EMAIL//'  /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh ${EMAIL}
}

configprosody() {
  AUHTLINE='authentication = "internal_plain"'
  sed -i "s/authentication\ \=\ \"anonymous\"/${AUTHLINE}/g" ${PROSODYPATH}
  cat << EOT >> ${PROSODYPATH}

VirtualHost "guest.${HOSTNAME}"
    authentication = "anonymous"
    c2s_require_encryption = false

EOT
}

configjitsi() {
        sed -i "s/\/\/\ anonymousdomain\:\ 'guest.example.com',/anonymousdomain\:\ 'guest.${HOSTNAME}',/g" ${JITSIPATH}
}

configjicofo() {
        echo "org.jitsi.jicofo.auth.URL=XMPP:${HOSTNAME}" >> ${JICOFOPATH}
}

registeruser(){
        PASSWORD=$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-16};echo;)
        prosodyctl register admin ${HOSTNAME} ${PASSWORD}
}

restartjitsi() {
        /opt/vultr/stopjitsi.sh
        /opt/vultr/startjitsi.sh
}

completedsetup(){
    echo ""
    echo "------------------------------"
    echo "|                            |"
    echo "|   JITSI SETUP COMPLETED!   |"
    echo "|                            |"
    echo "------------------------------"
    echo "JITSI URL: https://${HOSTNAME}"/
    echo ""
}

outputUser(){
    echo "USERNAME: admin"
    echo "PASSWORD: ${PASSWORD}"
    echo ""
}

# Script start

purgeold
reinstalljitsi
wipenginx
configssl
if [ "$AUTH" == "1" ]; then
    configprosody
    configjitsi
    configjicofo
    registeruser
    restartjitsi    
fi
completedsetup
if [ "$AUTH" == "1" ]; then
    outputUser
fi

Summary + More Reading

There you have it! With this project you can have a fully functional Jitsi instance on your own domain with end to end encryption in less than 5 minutes. When you are done, there’s no harm in deleting it so you aren’t charged.

Here are some references I used while creating this:

• https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
• https://www.vultr.com/docs/one-click-jitsi
• https://www.terraform.io/docs/providers/aws/d/route53_zone.html
• https://www.terraform.io/docs/providers/aws/r/route53_record.html
• https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
• https://www.terraform.io/docs/provisioners/connection.html#the-self-object
• Create Vultr API Key: https://my.vultr.com/settings/#settingsapi
• Create AWS Access/Secret Key: https://console.aws.amazon.com/iam/home?#security_credential
• Vultr API Reference – has examples that will get you plan, region, and app IDs. https://www.vultr.com/api/

The post Jitsi for Just in Time Conferencing using Terraform on Vultr with Route 53 appeared first on VirtJunkie.