Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated SSM Agent version #8

Merged
merged 1 commit into from
Feb 17, 2021

Conversation

WilboMo
Copy link
Contributor

@WilboMo WilboMo commented Feb 11, 2021

Issue number:
Fixes #7

Description of changes:
Bumps SSM Agent to latest available, 3.0.732.0, and updates S3 URL to the first region SSM Agent releases are deployed to.

Testing done:

Reviewed SSM Agent changelog for changes which would affect control-container usage and verified functionality of SSM Agent in control-container:

Confirmed control-container functionality by pushing a test image to ECR, pulling it into a Bottlerocket EKS stack as a replacement control-container. Verified enable-admin-container ran correctly and checked SSM agent in use is the correct version: 3.0.732.0.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

@WilboMo WilboMo changed the title Updated SSM Agent version, added jq Install Updated SSM Agent version Feb 11, 2021
Copy link
Contributor

@tjkirch tjkirch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like the main reasons for the 3.0 bump is Opt-in self update feature to upgrade if agent is running a deprecated version and Telemetry feature to send important audit events to AWS. Opt-in send to customer CloudWatch, which we wouldn't opt-in to.

It also has Monitor and keep the ssm-agent-worker process running in the 3.0 bump which makes me think we should inspect the differences with regard to how the agent service runs, just to make sure we're not worried about how it'll start/restart inside the control container. (e.g. they also mention Fix for systemd configuration to always restart the agent when it exits for any reason which is probably ok, but worth understanding.)

I looked through the rest of the changelog and didn't see anything that scared me.

VERSION Outdated Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
@WilboMo
Copy link
Contributor Author

WilboMo commented Feb 12, 2021

Sounds like the main reasons for the 3.0 bump is Opt-in self update feature to upgrade if agent is running a deprecated version and Telemetry feature to send important audit events to AWS. Opt-in send to customer CloudWatch, which we wouldn't opt-in to.

It also has Monitor and keep the ssm-agent-worker process running in the 3.0 bump which makes me think we should inspect the differences with regard to how the agent service runs, just to make sure we're not worried about how it'll start/restart inside the control container. (e.g. they also mention Fix for systemd configuration to always restart the agent when it exits for any reason which is probably ok, but worth understanding.)

I looked through the rest of the changelog and didn't see anything that scared me.

Thank you for calling those items out, I took a deeper look into them and found the following:

Fix for systemd configuration to always restart the agent when it exits for any reason:

This change sets the SSM Agent to restart regardless of the exit code. It also sets some logic to delay the restart to allow for reboots initiated by scripts. Should the exit code for the agent be 194 (reboot requested), it doesn't restart at all.

Monitor and keep the ssm-agent-worker process running:

It appears that this change introduced a worker which the core SSM Agent communicates with over IPC. There are a few channels which the agent and worker communicate over to determine worker health, process restart requests from the agent core and should the agent core terminate, allows the worker to determine if it should also terminate. Primarily the logic changes are around introduction of code to allow communication with the agent and worker, the overall functionality seems to be largely the same. Most of this is laid out in the agent/ipc/messagebu/respondent.go and agent/agent/agent.go files introduced/modified in release 3.0.151.0.

@WilboMo WilboMo marked this pull request as ready for review February 12, 2021 23:15
Copy link
Contributor

@etungsten etungsten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Copy link
Contributor

@zmrow zmrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🦅

Dockerfile Outdated Show resolved Hide resolved
Copy link
Contributor

@tjkirch tjkirch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@WilboMo WilboMo merged commit 42a8d6c into bottlerocket-os:develop Feb 17, 2021
@WilboMo WilboMo mentioned this pull request Feb 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bump SSM Agent version
4 participants