Skip to content

Support ECS volumes independent of EFS (for init containers) #408

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

Open
staticaland opened this issue Dec 4, 2024 · 7 comments
Open

Support ECS volumes independent of EFS (for init containers) #408

staticaland opened this issue Dec 4, 2024 · 7 comments
Labels

Comments

@staticaland
Copy link

staticaland commented Dec 4, 2024

Is your request related to a new offering from AWS?

No.

Is your request related to a problem? Please describe.

Currently, the module forces volume configuration to be tied to EFS (enable_efs). This means we can't use standard ECS volumes for common use cases like init containers that need to share files with the main Atlantis container.

A specific example is needing to configure Atlantis Slack webhooks, which according to the documentation must be configured via the server side config file. This is not the same as the server-side repo config.

  • ATLANTIS_REPO_CONFIG is the path to the server-side repo config.
  • ATLANTIS_REPO_CONFIG_JSON lets you specify the server-side repo config as a JSON string directly
  • ATLANTIS_CONFIG is the path to the server-side config.
  • There is no JSON string option like the repo config has.

Describe the solution you'd like.

Allow volume configuration to work independently of the EFS setting. Something like this:

volume = { for k, v in merge(
    var.enable_efs ? {
      efs = {
        efs_volume_configuration = {
          file_system_id     = module.efs.id
          transit_encryption = "ENABLED"
          authorization_config = {
            access_point_id = try(module.efs.access_points["atlantis"].id, null)
            iam             = "ENABLED"
          }
        }
      }
    } : {},
    lookup(var.service, "volume", {})
) : k => v if k == "efs" ? var.enable_efs : true }

I'm not 100% sure this code is correct for all cases, but it works in my case.

This enables use cases like:

service = {
  volume = {
    atlantis-config = {
      name = "atlantis-config"
    }
  }
  container_definitions = {
    init-config = {
      mount_points = [{
        sourceVolume = "atlantis-config"
        containerPath = "/config"
      }]
    }
  }
}
  atlantis = {
    dependencies = [
      {
        containerName = "init-config"
        condition     = "COMPLETE"
      }
    ]
    mount_points = [
      {
        sourceVolume  = "atlantis-config"
        containerPath = "/etc/atlantis"
        readOnly      = true
      }
    ]
}

I can show a full example if necessary.

Describe alternatives you've considered.

  1. Use EFS - but I feel it's unnecessary.
  2. Use enable_efs = true with create = false - but this isn't possible as creation is tied to enable_efs. Even if it did work, it would be an ugly solution.
Copy link

github-actions bot commented Jan 5, 2025

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Jan 5, 2025
@staticaland
Copy link
Author

staticaland commented Jan 6, 2025

Still valuable 🤗

@github-actions github-actions bot removed the stale label Jan 7, 2025
Copy link

github-actions bot commented Feb 7, 2025

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Feb 7, 2025
@am-zest
Copy link

am-zest commented Feb 13, 2025

I have the same issue. I need this!

Copy link

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Mar 16, 2025
@yngvark
Copy link

yngvark commented Mar 25, 2025

Still need this.

@github-actions github-actions bot removed the stale label Mar 26, 2025
Copy link

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Apr 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants