-
Notifications
You must be signed in to change notification settings - Fork 524
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
Initial prototype of aws-ecs-1 variant #946
Conversation
(Note: CI failures are due to new package sources not being available in the cache yet.) |
packages/ecs-init/0001-bottlerocket-remove-interaction-with-Nvidia-lib.patch
Outdated
Show resolved
Hide resolved
packages/ecs-init/0002-docker-do-not-bind-mount-missing-plugin-dirs.patch
Outdated
Show resolved
Hide resolved
packages/ecs-init/README.md
Outdated
create any directory that does not exist, and `/usr/lib/docker/plugins` is | ||
such a directory that does not exist. However, Bottlerocket's filesystem is | ||
mostly read-only, and ecs-init fails to create this directory. For now, | ||
bind-mounting is skipped when a directory does not exist, but this will break |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with how plugins are used, what functionality would this limit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker plugins can be installed into those directories, see here. The agent scans these directories to discover unmanaged plugins. However, it does look like "managed" plugins (installed via the "docker plugin install" command) are typically installed into /run/docker/plugins
which does work on Bottlerocket. It's probably reasonable for us to only support managed plugins on Bottlerocket, or unmanaged plugins built into Bottlerocket itself.
52656d8
to
cdfe816
Compare
(GitHub won't let me reply on this) @bcressey wrote:
Probably not; this is one of the items in the README.md that I was looking for another way around. I don't really see a use-case for un-setting these options when ecs.service stops, but I also don't want to re-run the setup commands every time the service starts. My current idea (which I have not tried yet) is to move all these setup commands to a separate oneshot systemd service that the main ecs.service depends on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Impressive opus!
packages/ecs-agent/0002-bottlerocket-default-filesystem-locations.patch
Outdated
Show resolved
Hide resolved
The systemd cgroup driver imposes additional restrictions on the name of cgroup parents, causing workflows that depend on non-conforming names to fail.
This macro can be used for conditions in variant-specific packages like `os`.
ecs-settings-applier is built conditionally for aws-ecs-1. Attempting to compile ecs-settings-applier for another variant will fail, as the applier depends on the definition of model::Model in the ECS variant.
The default docker0 bridge allows container networking to function in a familiar way to developers. The bridge is used by `docker run` when exposing ports and used by Amazon ECS.
Issue number:
#815
Description of changes:
This pull request introduces a new variant of Bottlerocket called aws-ecs-1. The new variant includes the ECS agent and Docker to run containers.
The commits here represent the skeleton for packaging the ECS agent, defining the ECS model in the Bottlerocket API, rendering appropriate config, and making the new variant. I'd like to merge this (after review, of course) and then continue iterating on the variant in subsequent PRs.
Testing done:
Launched an AMI from this variant, observed that it connected to a non-default cluster (configured with the new
settings.ecs.cluster
setting) in ECS, and ran a basic task with minimal features (busybox:latest running sleep).Set the new
settings.ecs.instance-attributes
setting through TOML-formatted user-data. Observed that the attributes are registered properly, along with the defaultbottlerocket.variant
andbottlerocket.version
attributes.Toggled the new
settings.ecs.privileged-containers-enabled
setting through the Bottlerocket API. Observed that the config file was properly regenerated, the agent restarted, and the capabilities updated in the ECS API.Validated that the pause container image is automatically loaded and able to run.
If you wish to test this variant, you can use this user-data:
Note: I have not yet updated the top-level README as the variant is not really ready for use yet. This means that the settings are currently undocumented.
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.