3 Febbraio 2019

Understanding AWS System Manager - Part 1

AWS Systems Manager allows you to centralize operational data from multiple AWS services and automate tasks across your AWS resources. This is the 1st part of the series.

Understanding AWS System Manager

AWS Systems Manager allows you to centralize operational data from multiple AWS services and automate tasks across your AWS resources. You can create logical groups of resources such as applications, different layers of an application stack, or production versus development environments. With Systems Manager, you can select a resource group and view its recent API activity, resource configuration changes, related notifications, operational alerts, software inventory, and patch compliance status. You can also take action on each resource group depending on your operational needs. Systems Manager provides a central place to view and manage your AWS resources, so you can have complete visibility and control over your operations.

 

What is AWS System Manager?

 

  1. A set of fully managed AWS services and capabilities;

  2. Enables automated configuration and ongoing management of systems at scale;

  3. Both for Windows and Linux operative system;

  4. For servers running on EC2 or on premise;

  5. Helps accelerate cloud journey;

  6. Flexible and easy to use automation-focused approach.

 

 The key benefits of SSM are:

 

  1. Hybrid (can works on EC2 as well on premise);

  2. Cross platform support (the same tools are available to both Windows and Linux platforms);

  3. Scalable (is designed for cloud scale and both for long running instances or for environment that scale quickly);

  4. AWS Optimized (full integrated with IAM for auth, CloudTrail for auditing, CloudWatch for monitoring);

  5. No additional charges (don’t worry about licenses).

 

SSM creates an additional value for solution at top level of architecture.

 

 Which problems SSM resolves?

 

  1. Traditional IT toolsets aren’t designed and build for cloud scale (agility and elasticity);

  2. Deploying and maintaining multiple products is a significant operational overhead;

  3. Licensing costs and complexity

 

Building blocks of System Manager

 

System Manager is made by:

 

  1. SSM Agent: executes task or requests coming from System Manager;

  2. Documents: where you define your configurations or tasks you want to perform in your infrastucture; essentially, they are a list of task that must be executed in sequence. Documents can be versioned and shared. The can be used cross the System Manager (RunCommand, etc).

  3. System Manager is accessibile via Console or AWS-CLI, Windows or Linux systems.

Setting UP IAM

There are 3 core prerequisites for running System Manager:

  1. System Manager IAM Role: you need to setup 2 roles:

    1. role that authorize you to use System Manager ;

    2. role to allow an instance to be managed by System Manager.

  2. SSM Agent: this is the agent installed on your instance that communicate with System Manager. As know, it can be installed on premise or on EC2 instances.

  3. Internet Access: EC2 requires outbound internet access, inbound internet access aren’t required.

 

1a. Authorize user to use System Manager

 

On console, select IAM, and setup an user with a role that provides access to system Manager.

Go to Users, and create a new user w/out any permission, or use an existing user. In this example, we’ll use “Mario” as user. Click on Mario, and “Add permissions”; “Attach existing policies directly”; search for “SSM” and select “AmazonSSMFullAccess” checkbox, “Review” and “Add Permissions”.

On this step, you granted the user “Mario” with access to the System Manager by using the manager policy” AmazonSSMFullAccess”; you can achieve the same result attaching the same policy to an existing Group of users that “Mario” belongs to.

 

 

 

1b. Instance profile to enable System Manager Management of the instance

 

On console, select IAM, choose “Create a New Role” under “Roles”; set a Role Name (myManagedInstanceRoleforSSM), click “Amazon EC2” and there select or search “AmazonEC2RoleforSSM”, and create that role.

2. SSM Agent installation

 

The instructions provided here are for Ubuntu Servers.

 

Connect to your Ubuntu Server instance and perform the steps in one of following procedures to install SSM Agent on each instance that will run commands using Systems Manager.

 About SSM Agent installations on 64-bit Ubuntu Server 16.04 instances

Beginning with instances created from Ubuntu Server 16.04 AMIs identified with 20180627, SSM Agent is pre-installed using Snap packages. For example: ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180627. On instances created from earlier AMIs, you should continue using deb installer packages.

Important

Be aware that if an instance has more than one installation of the SSM Agent (for example, one installed using a Snap, one installed using a deb installer), your agent operations will not work correctly.

You can check the source AMI ID for an instance following these steps:

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. In the left navigation, choose Instances.

  3. Select an instance.

  4. On the Description tab, locate the value in the AMI ID field.

For instances created from a 64-bit Ubuntu Server 16.04 AMI, be sure to follow the correct procedure for your SSM Agent installation type:

 Install SSM Agent on Ubuntu Server 18.04 and 16.04 instances (Snap package)

SSM Agent is installed, by default, on Ubuntu Server 18.04 and on 16.04 LTS 64-bit AMIs with an identifier of 20180627 or later. For more information about version 16.04 AMIs, see About SSM Agent installations on 64-bit Ubuntu Server 16.04 instances.

You can use the following script if you need to install SSM Agent on an on-premises server or if you need to reinstall the agent. You don't need to specify a URL for the download, because the snap command automatically downloads the agent from the Snap app store at https://snapcraft.io.

 

sudo snap install amazon-ssm-agent –classic

 

Note

Note the following details about SSM Agent on Ubuntu Server 18.04 and 16.04:

systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service
  • On Ubuntu Server 18.04 and 16.04, SSM Agent installer files, including agent binaries and config files, are stored in the following directory: /snap/amazon-ssm-agent/current/. If you make changes to the config files (amazon-ssm-agent.json.template and seelog.xml.template) then you must copy these files from the /snap folder to the /etc/amazon/ssm/ folder. Log and library files have not changed (/var/lib/amazon/ssm,/var/log/amazon/ssm).
  • Because of a known issue with Snap, you might see a Maximum timeout exceeded error with snap commands. If you get this error, run the following commands one at a time to start the agent, stop it, and check its status:
  • On Ubuntu Server 18.04, use Snaps only. Don't install deb packages. Also verify that only one instance of the agent is installed and running on your instances.
  • On Ubuntu Server 18.04 and 16.04, SSM Agent provides support for the arm64 processor architecture.
  • On Ubuntu Server 16.04, SSM Agent is installed using either Snaps or deb installation packages, depending on the version of the 16.04 AMI. For more information, see About SSM Agent installations on 64-bit Ubuntu Server 16.04 instances.

 

  1. Run the following command to determine if SSM Agent is running.

     

    sudo snap list amazon-ssm-agent

     

  2. Run the following command to start the service if the previous command returned amazon-ssm-agent is stoppedinactive, ordisabled.

     

    sudo snap start amazon-ssm-agent

     

  3. Check the status of the agent.

     

    sudo snap services amazon-ssm-agent

     

Note

SSM Agent is updated whenever changes are made to Systems Manager and when new capabilities are added. To ensure that your instances are always running the newest version of SSM Agent, we recommend that you create a State Manager association that automatically updates SSM Agent when a new version is available. You can also use Run Command to quickly update one or more instances with the latest version. For more information, see Automatically Update SSM Agent (CLI) (State Manager) and Update SSM Agent by using Run Command.

 

Install SSM Agent on Ubuntu Server 16.04 and 14.04 (deb installer package)

  1. You can use the following script if you need to install SSM Agent on an on-premises server or if you need to reinstall the agent.

    Important

    SSM Agent is installed by default on instances created from Ubuntu Server 16.04 LTS 64-bit AMIs witInstall SSM Agent on Ubuntu Server 16.04 and 14.04 64-bit instances (with deb installer package)h an identifier of20180627 or later. Instances created from AMIs with earlier identifiers, for example 20171121.1 and 20180522, should continue to use deb installers.

    If SSM Agent is installed on your instance in conjunction with a Snap and you install or update SSM Agent using a deb installer package, the installation or SSM Agent operations may fail. For more information, see About SSM Agent installations on 64-bit Ubuntu Server 16.04 instances

    Create a temporary directory on the instance.

     

    mkdir /tmp/ssm

     

    Change to the temporary directory.

     

    cd /tmp/ssm

     

    Run the following commands.

     

     

    Run the command:

     

    sudo dpkg -i amazon-ssm-agent.deb
 
  1. Run one of the following commands to determine if SSM Agent is running.

    Ubuntu Server 16.04:

     

    sudo systemctl status amazon-ssm-agent

     

    Ubuntu Server 14.04:

     

    sudo status amazon-ssm-agent

     

  2. Run one of the following commands to start the service if the previous command returned amazon-ssm-agent is stopped,inactive, or disabled.

    Ubuntu Server 16.04:

     

    sudo systemctl enable amazon-ssm-agent

     

    Ubuntu Server 14.04:

     

    sudo start amazon-ssm-agent

     

  3. Run one of the following commands to check the status of the agent.

    Ubuntu Server 16.04:

     

    sudo systemctl status amazon-ssm-agent

     

    Ubuntu Server 14.04:

     

    sudo status amazon-ssm-agent

     

Note

 

SSM Agent is updated whenever changes are made to Systems Manager and when new capabilities are added. To ensure that your instances are always running the newest version of SSM Agent, we recommend that you create a State Manager association that automatically updates SSM Agent when a new version is available. You can also use Run Command to quickly update one or more instances with the latest version. For more information, see Automatically Update SSM Agent (CLI) (State Manager) and Update SSM Agent by using Run Command.

 

Once the steps are completed, the instances are definded as Managed Instances.

There are 3 method to create a managed instance:

  1. create new instance,

  2. associate existing instances with IAM role,

  3. associate an on-premise instance with SSM.

 

For the 3rd option you need to “Create Activation”, choose the already created IAM Role, and define the Activation Expiry Date (expiration for the Activation process, not the access to SSM). You will finally get the Activation Code and Activation ID. Keep them in safe place.

 

The procedure to activate an external (on-premise) instance is the following section.

 

 

Install SSM Agent on Servers and Virtual Machines in a Linux Hybrid Environment

 

For Ubuntu Server 64-bit

 

mkdir /tmp/ssm
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop
sudo amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region"
sudo service amazon-ssm-agent start

 

Note

If you see the following error in the SSM Agent error logs, then the machine ID did not persist after a reboot:

 

Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint does not match

 

Execute the following command to make the machine ID persist after a reboot.

 

umount /etc/machine-id
systemd-machine-id-setup


End of part 1


Il blog di msg4u

Una raccolta di articoli piĆ¹ o meno tecnici per sfruttare al meglio cloud e posta elettronica.