Labs for Linux on Azure

These are full lab environments that I've created to demonstrate many different Linux topics. They are also provided with ARM templates to create full, isolated Azure environments.

These labs are focused on CentOS7, thus are helpful to study for RHCSA, RHCA, LFCS, and LFCE certifications. The Azure focus is helpful to study Azure IAAS as seen in exam 70-533. Though, the focus is more on Linux than on Azure. They have been updated for Azure CLI 2.

Note: not all labs are properly for Azure. PXE on Azure makes little to no sense. You can use Hyper-V or whatever for those.

Due to the nature of these, they are naturally unattended. Few things are more annoying than an having to actually interact with something directly (e.g. entering a password, editing a file). Script it and be done with it.

In your own labs, you might considering following the modular development method that I've proposed in my post Developing Azure Modular ARM Templates.

Creation

You can create most labs in two parts.

First, create your resource group (stick with alphanumeric group names):

az group create --location centralus --name mongodb

Second, deploy with parameters (look through the azuredeploy.json of a particular project to see what parameters are needed):

az group deployment create --name burrito01 --resource-group mongodb --template-uri https://linux.azure.david.betz.space/raw/mongodb/azuredeploy.json --parameters "{\"admin-username\":{\"value\":\"$USER\"},\"ssh-public-key\":{\"value\":\"`cat ~/.ssh/id_rsa.pub`\"}}"

This particular example will setup a MongoDB server with MongoDB installed, data imported, and users created. You can then run a generation script to generate mass data.

Always review the azuredeploy.json file to see what parameters are required. The following example deploys a multi template:

Second, deploy with parameters (look through the azuredeploy-parameters.json of a particular project to see what parameters are needed):

az group deployment create --name burrito01 --resource-group multi --template-uri https://linux.azure.david.betz.space/raw/multi/azuredeploy.json --parameters "{\"admin-username\":{\"value\":\"$USER\"},\"ssh-public-key\":{\"value\":\"`cat ~/.ssh/id_rsa.pub`\"}, \"vm-count\": { \"value\": 3 } }"

Lab Types

Some labs are templates of templates while others are very specific to demonstrate full concepts (e.g. LVM). These are used as templates to create other labs.

Labs with more than one system create all the systems. The NFS lab, for example, spins up two machines and runs nfs/install-server.sh or nfs/setup-client.sh. Then you can view nfs/verification.txt to run verification commands.

Templates of templates include simple, multi, and public-private.

simple - creates one public system
multi - creates N-public systems (where N is vm-count parameter)
public-private - creates two-systems; alpha is public, beta is private. You ssh to alpha to ssh into beta.

Keep in mind that the associated install scripts can easily be reused on Hyper-V virtual machines. That's where most of them originated anyway.

Finally, yes... everything is run as root. That's how the provisioning works. If you use these locally, add sudo where needed or whatever. That said, the overwealming majority of all scenarios will be in a VM. Therefore, you should be snapshotting your servers regularly during setup anyway. If your VM software doesn't provide bit-level, point-in-time recovery (like standard checkpoints in Hyper-V), get a better VM service. No, Hyper-V's rediculous "Production Checkpoints" don't help.

Management

To get the DNS use the following:

az network public-ip list --query "[?dnsSettings.domainNameLabel!=null]|[?starts_with(dnsSettings.domainNameLabel,'dev01')].{ dns: dnsSettings.fqdn  }"

To delete stuff, use delete.sh:

./delete random01
./delete random02
./delete random03
./delete random04

That's much better than the horribly verbose and slow, poorly designed VB-style PowerShell commands.

PowerShell isn't horrible when you realize it's the .NET REPL. If you do your PowerShell in a hyper purist, anti-intuitive manner (e.g. using Get-ChildItem instead of the cleaner and more natural ls) you'll 1) end up making more people hate it, and 2) make it look like VB6 (as many MSDN examples do!) Linux sysadmins know both Bash and Python. Every Windows sysadmin is required to know PowerShell, THEREFORE know .NET. PowerShell is .NET. PowerShell is programming. Plot twist: so is JSON template development.

Intent

There isn't as big of a gap between systems engineering and software engineering as some people think. There is SUBSTANTIAL OVERLAP. Software engineers need to be DBAs (thus knowing that code-first database generation is destructive to indexes and should never be tolerated) and systems engineers must have serious scripting skills. This becomes obvious for software engineers once you deal with HTTP verb routing (e.g. GET goes to this server/POST goes to that other server), web farms, and anything even remotely touching security. This type of overlap is the target of these labs.

Hyper-V

A few of the topics here are actually for Hyper-V. PXE boot, for example, uses hyperv_create.ps1 to spin up a local VMs. If you do it right, you can create your own full local cloud environment (I guess we could call that "fog").