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

Support for init container in azurerm_container_group #8085

Closed
johnksv opened this issue Aug 11, 2020 · 8 comments
Closed

Support for init container in azurerm_container_group #8085

johnksv opened this issue Aug 11, 2020 · 8 comments

Comments

@johnksv
Copy link

johnksv commented Aug 11, 2020

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The provider should support init containers in Container Instances, as available through the CLI and as described here:

https://docs.microsoft.com/en-us/azure/container-instances/container-instances-init-container

New or Affected Resource(s)

  • azurerm_container_group

Potential Terraform Configuration

resource "azurerm_container_group" "group" {
  …
  init_container {
    cpu = 0
    image = ""
    memory = 0
    name = ""
  }
  …
}

References

@allantargino
Copy link
Contributor

Hi @ArcturusZhang,
Did you start working on this feature? If not I am happy to help.

@allantargino
Copy link
Contributor

allantargino commented Jan 3, 2021

Inspecting the current interface, I suppose we will have some problems with Volumes when introducing Init Containers, giving that both Containers and Init Containers should have the ability to share volumes.

That's the current [*].container.[*].volume:

volume {
    name = ""

    mount_path = ""
    read_only = false

    share_name = ""
    storage_account_name = ""
    storage_account_key = ""

    empty_dir = false

    secret = {
        "a" : "b"
    }

    git_repo {
        url = ""
        directory = ""
        revision = ""
    }
}

It merges the concepts of both Volume Mounts and Volumes into one abstraction.

I would propose deprecating [*].container.[*].volume, in favor of the new [*].container.[*].volume_mount and [*].volume.

This is a proposal for [*].container.[*].volume_mount:

volume_mount {
    volume_name = ""
    mount_path = ""
    read_only = false
}

Where volume_name must reference a [*].volume.name.

This is a proposal for [*].volume:

volume {
    name = ""

    azure_file {
        share_name = ""
        storage_account_name = ""
        storage_account_key = ""
    }

    empty_dir = false

    secret = {
        "a" : "b"
    }

    git_repo {
        url = ""
        directory = ""
        revision = ""
    }
}

I am also proposing grouping all file share properties under the new azure_file property.

While being deprecated, we can still support [*].container.[*].volume, but they won't be able to share volumes with init containers. Also, as any volumes today, volume names will have to be unique across both [*].container.[*].volume and [*].volume

After these changes, I believe we shouldn't have problems introducing volumes to Init Container using the same abstractions.

This aligns with ARM template structure: https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files#mount-multiple-volumes

Thoughts?
cc/ @ArcturusZhang, @afdezl, @njuCZ, @katbyte, @tombuildsstuff

@ArcturusZhang
Copy link
Contributor

Hey @allantargino appreciate if you could start - I only have a very simple start and then occupied by something else.
The design is very reasonable, thanks for the contribution!

@ArcturusZhang ArcturusZhang removed their assignment May 20, 2021
@bdhar1
Copy link

bdhar1 commented Nov 1, 2021

Hi @ArcturusZhang / @allantargino ,

Any update on this issue? This can really help with the ACI usage.

Thanks in advance.

@allantargino
Copy link
Contributor

allantargino commented Nov 1, 2021

Hi @bdhar1, I ended up not implementing on this feature.

@hterik
Copy link
Contributor

hterik commented Dec 14, 2021

Sharing volumes between containers is now supported using emptyDir, since #13374
When adding initContainers i believe it should be possible to use same mechanism.
Sharing other type of volume mounts makes less sense, so new mode of defining volumes shouldn't block this feature.

katbyte pushed a commit that referenced this issue Apr 12, 2022
Co-authored-by: zjhe <hezijie@microsoft.com>

An enhancement as #8085 described.
@lonegunmanb
Copy link
Contributor

Hello @johnksv and everyone, the init_container has been introduced into the container group resource from v3.2.0. Would you please close this issue? Many thanks!

@johnksv johnksv closed this as completed Apr 16, 2022
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants