terraform-provider-azurerm icon indicating copy to clipboard operation
terraform-provider-azurerm copied to clipboard

container_group_resource: Ports property listed as optional but is required

Open lawrencegripper opened this issue 3 years ago • 10 comments

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

Terraform (and AzureRM Provider) Version

Terraform v0.13.5
+ provider registry.terraform.io/hashicorp/azurerm v2.51.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.0.1
+ provider registry.terraform.io/hashicorp/time v0.7.0

Affected Resource(s)

  • azurerm_container_group

When deploying a container without any ports specified an error is returned

Terraform Configuration Files

resource "azurerm_container_group" "build_agent" {
  name                = "buildagent"
  location            = azurerm_resource_group.env.location
  resource_group_name = azurerm_resource_group.env.name
  tags                = var.tags

  network_profile_id = azurerm_network_profile.buildagent.id
  ip_address_type    = "Private"

  os_type = "Linux"

  image_registry_credential {
    username = var.docker_registry_username
    password = var.docker_registry_password
    server   = var.docker_registry_url
  }

  container {
    name     = "buildagent"
    image    = var.azp_docker_image
    cpu      = "1"
    memory   = "2"
    commands = ["bash", "-f", "./buildagentstart.sh"]

    environment_variables = {
      // The URL of the Azure DevOps or Azure DevOps Server instance.
      AZP_URL = var.azp_url
      // Personal Access Token (PAT) with Agent Pools (read, manage) scope, created by a user who has permission to configure agents, at AZP_URL.
      AZP_TOKEN = var.azp_token
      // Agent name (default value: the container hostname).
      AZP_AGENT_NAME = local.shared_env.rg.name
      // Agent pool name (default value: Default).
      AZP_POOL = local.shared_env.rg.name
      // Work directory (default value: _work).
      AZP_WORK = "_work"
    }
  }
}

Debug Output

Panic Output

Expected Behaviour

Creation to succeed as docs/schema flag ports property as optional

https://github.com/terraform-providers/terraform-provider-azurerm/blob/2996ca7d66ccfe0a80550e600818813fd294eb59/azurerm/internal/services/containers/container_group_resource.go#L244-L269

Actual Behaviour

The ports '0' are invalid for container 'downloader' in container group 'downloader'. The port must be beteween 1 and 65535.

Error: Error creating/updating container group "mesh-downloader-kmben" (Resource Group "crimp-processing-daves"): containerinstance.ContainerGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="InvalidContainerPorts" Message="The ports '0' are invalid for container 'downloader' in container group 'downloader'. The port must be beteween 1 and 65535."
  on ../modules/container_instance/main.tf line 16, in resource "azurerm_container_group" "mesh_downloader":
  16: resource "azurerm_container_group" "mesh_downloader" {

Steps to Reproduce

  1. terraform apply

Important Factoids

The Azure Spec agrees, partially, that on a port the port property is required and protocol is optional.

https://github.com/Azure/azure-rest-api-specs/blob/961799e77f5e9b81208384a1c6ce3a6bc9e84a93/specification/containerinstance/resource-manager/Microsoft.ContainerInstance/stable/2018-04-01/containerInstance.json#L933

References

lawrencegripper avatar Mar 24 '21 16:03 lawrencegripper

The spec suggests that having no ports at all is an option, if I'm reading it correctly, so I'm not sure if this is a case of the item defaulting to an invalid port when no ports are set or the spec being incorrect.

lawrencegripper avatar Mar 24 '21 17:03 lawrencegripper

There is some discussion as well on #1697 as to whether ports should be optional or not.

amasover avatar May 06 '21 23:05 amasover

Hi @lawrencegripper any workaround for this particular usecase? I'm also trying to deploy a vsts devops agent using containers

xaviergxf avatar Feb 21 '22 08:02 xaviergxf

Was a while back now but iirc I deployed with some ports specified and it worked.

lawrencegripper avatar Feb 22 '22 10:02 lawrencegripper

@lawrencegripper port is required within the ports, while ports itself is optional to support ip_address_type = None. So the current schema definition LGTM.

magodo avatar May 09 '22 11:05 magodo

The error here is that I didn't specify a ports block, see original Terraform file at the top of the issue. This resulted in the following error:

Error: Error creating/updating container group "mesh-downloader-kmben" (Resource Group "crimp-processing-daves"): containerinstance.ContainerGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="InvalidContainerPorts" Message="The ports '0' are invalid for container 'downloader' in container group 'downloader'. The port must be beteween 1 and 65535."
  on ../modules/container_instance/main.tf line 16, in resource "azurerm_container_group" "mesh_downloader":
  16: resource "azurerm_container_group" "mesh_downloader" {

If ports can only be optional while none is set on ip_addresss_type then TF should validate that and provide an error rather than an apply time error.

lawrencegripper avatar May 09 '22 12:05 lawrencegripper

@lawrencegripper port is required within the ports, while ports itself is optional to support ip_address_type = None. So the current schema definition LGTM.

@magodo - This is not okay this way, I have to agree with @lawrencegripper. I ran into the same issue. In case the ip_addresss_type is either Private or None, we should be able to specify a container group without exposed ports - which is currently not the case.

Dilergore avatar Mar 22 '23 09:03 Dilergore

had the same issue. It doesn't even suffice to use exposed_port since you need at least one container with a ports block. I tried dynamically creating multiple containers but this causes also an error, since you're not allowed to expose the same ports in another container.

What I did was manually creating at least one container with a ports block and the rest dynamically without them.

Degooya avatar Feb 27 '24 14:02 Degooya

@lawrencegripper With the current provider version (v3.93.0), using your above config will return:

│ Container Group Name: "acctestcontainergroup-220719133700697922"): performing ContainerGroupsCreateOrUpdate: containerinstance.ContainerInstanceClient#ContainerGroupsCreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="MissingIpAddressPorts" Message="The ports in the 'ipAddress' of container group 'acctestcontainergroup-220719133700697922' cannot be empty."

This seems reasonable.

magodo avatar Feb 28 '24 01:02 magodo

@Dilergore For private ip address type, the port is still required. While for None, the ports are not set to the API at all.

magodo avatar Feb 28 '24 01:02 magodo