Skip to content

Linux, Cisco, Windows, Azure, AWS & VMware automated deployment and management

Notifications You must be signed in to change notification settings

brianstinehart/AzureAWSVMware

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Ansible Deployment at Interactive

These ansible playbooks provision and manage Linux and Windows VMs on VMware, Azure or AWS. This provisions the following:

  • Base Infrastructure
    • A Windows 2019 server
    • A Linux 7.5 server
  • Optional Additions
    • A Microsoft Active Directory Server
    • An Ansible Tower control node
    • A Gitlab server
    • A Windows Workstation

The client pre-requisite to use this workshop is simply to have an RDP client which can connect to the Windows Workstation. If RDP is not allowed through a corporate firewall, a HTML5 RDP client is also running on each Workstation. As the HTML5 client is fairly slow, it is recommended that students use normal RDP if at all possible. All other activities will take place from that Workstation. The Workstation has Visual Studio Code, Chrome, Putty, and Git for Windows.

Usage

Basic Requirements

Requirements for running the provisioner will vary based upon your environment and where you are provisioning to. The basic requirements are the following

  • Ansible >= 2.6
  • Various Python Modules
    • pywinrm
    • boto >= 1.7 and boto3 (for AWS Provisioning)
    • ansible[azure] (for Azure Provisioning)
    • requests
    • requests-credssp
    • sshpass (use brew to install if OSX)
  • Ansible Tower License (if Tower server is deployed)

General Config

Beyond that, the main thing that needs to be edited is the vars/main.yml file which contains the configuration details specific to your environment. You should instead copy this file to vars/custom.yml and it will use that in place of the main.yml file. It will check for the custom.yml file first, and use main.yml if its not found. This ensure your settings are not overridden if you update git, and are not committed to git (this file is ignored).

It is recommended that you utlilize the custom.yml to maintain the majority of the nonchanging settings, and then you can create a separate vars file (to be included in via extravars) with just the variables you need for the individual workshop.

## Example extra vars file
instance_loc: azure
name_prefix: "skylight"
user_count: 1   #for number of servers to deploy in each flavour
towerversion: 3.5.2-1

That's it. Easy, right ?!? Now run it as you wish :)

AWS

You will need to setup your AWS configuration and Credentials. Note that a standard AWS account is limited to 20 ec2 instances, so update your quota in advance. Also note that each student gets 3 machines. Make certain your VPC is large enough.

You can set it up like this.

~/.aws/config

[default]
region = us-east-1
output = table

~/.aws/credentials

[default]
aws_access_key_id = <your ec2 access key>
aws_secret_access_key = <your ec2 secret key>

Azure

Azure CLI

sudo pip install azure

Possible need to register the provider

az provider register --namespace Microsoft.Compute

Firstly, login to the Azure CLI using:

az login

Once logged in - it's possible to list the Subscriptions associated with the account via:

az account list

The output (similar to below) will display one or more Subscriptions - with the id field being the subscription_id field.

[
  {
    "cloudName": "AzureCloud",
    "id": "00000000-0000-0000-0000-000000000000",
    "isDefault": true,
    "name": "PAYG Subscription",
    "state": "Enabled",
    "tenantId": "00000000-0000-0000-0000-000000000000",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

Note id above maps to azure_subscription_id in the vars/main.yml file.

Should you have more than one Subscription, you can specify the Subscription to use via the following command:

az account set --subscription="SUBSCRIPTION_ID"

We can now create the Service Principal which will have permissions to manage resources in the specified Subscription using the following command:

az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/SUBSCRIPTION_ID"

This command will output 5 values:

{
  "appId": "00000000-0000-0000-0000-000000000000",
  "displayName": "azure-cli-2017-06-05-10-41-15",
  "name": "http://azure-cli-2017-06-05-10-41-15",
  "password": "0000-0000-0000-0000-000000000000",
  "tenant": "00000000-0000-0000-0000-000000000000"
}

These values map to the variables like so in the vars/main.yml file:

  • appId is azure_client_id
  • password is azure_secret
  • tenant is azure_tenant

Lastly, you can lookup Azure regions/locations that map to azure_location in the vars/main.yml file using the following command:

az account list-locations --query "[].{DisplayName:displayName, Name:name}" -o table

And now you can test these values work as expected by logging in:

az login --service-principal -u CLIENT_ID -p CLIENT_SECRET --tenant TENANT_ID

About

Linux, Cisco, Windows, Azure, AWS & VMware automated deployment and management

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published