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

Initial prototype of aws-ecs-1 variant #946

Merged
merged 28 commits into from
Jul 27, 2020

Conversation

samuelkarp
Copy link
Contributor

@samuelkarp samuelkarp commented Jun 16, 2020

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 default bottlerocket.variant and bottlerocket.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:

[settings.ecs]
cluster = "bottlerocket"

[settings.ecs.instance-attributes]
hello = "world"

[settings.host-containers.admin]
enabled = true

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.

@samuelkarp samuelkarp requested a review from jahkeup June 16, 2020 21:40
packages/docker-engine/daemon.json Show resolved Hide resolved
packages/ecs-init/ecs-init.spec Outdated Show resolved Hide resolved
packages/ecs-init/ecs-init.spec Outdated Show resolved Hide resolved
@samuelkarp
Copy link
Contributor Author

(Note: CI failures are due to new package sources not being available in the cache yet.)

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
Copy link
Member

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?

Copy link
Contributor Author

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.

variants/aws-ecs-1/Cargo.toml Show resolved Hide resolved
packages/ecs-agent/README.md Outdated Show resolved Hide resolved
sources/models/src/lib.rs Outdated Show resolved Hide resolved
packages/ecs-agent/ecs.service Outdated Show resolved Hide resolved
packages/ecs-agent/ecs.service Outdated Show resolved Hide resolved
packages/ecs-agent/Cargo.toml Outdated Show resolved Hide resolved
packages/ecs-agent/ecs-agent.spec Outdated Show resolved Hide resolved
packages/ecs-agent/ecs-agent.spec Outdated Show resolved Hide resolved
packages/ecs-agent/ecs-agent.spec Outdated Show resolved Hide resolved
@samuelkarp
Copy link
Contributor Author

(GitHub won't let me reply on this)

@bcressey wrote:

Do we need to set net.ipv4.conf.all.route_localnet back to the default value on stop? Might be easiest to just remove it.

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.

Copy link
Contributor

@webern webern left a comment

Choose a reason for hiding this comment

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

Impressive opus!

sources/api/ecs-settings-applier/src/main.rs Outdated Show resolved Hide resolved
packages/ecs-agent/Cargo.toml Outdated Show resolved Hide resolved
packages/ecs-agent/ecs-agent.spec Show resolved Hide resolved
packages/os/os.spec Show resolved Hide resolved
sources/api/ecs-settings-applier/Cargo.toml Outdated Show resolved Hide resolved
sources/api/ecs-settings-applier/src/main.rs Outdated Show resolved Hide resolved
sources/models/src/modeled_types/ecs.rs Outdated Show resolved Hide resolved
sources/models/src/modeled_types/ecs.rs Outdated Show resolved Hide resolved
sources/models/src/modeled_types/ecs.rs Outdated Show resolved Hide resolved
sources/models/src/modeled_types/ecs.rs Outdated Show resolved Hide resolved
sources/models/src/modeled_types/ecs.rs Outdated Show resolved Hide resolved
samuelkarp and others added 24 commits July 24, 2020 18:44
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.
@samuelkarp samuelkarp merged commit 988c0de into bottlerocket-os:develop Jul 27, 2020
@samuelkarp samuelkarp deleted the ecs branch July 27, 2020 22:29
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.

8 participants