Network

The network resource creates isolated Docker networks for containers to communicate. Networks provide network isolation and allow containers to discover each other using container names or aliases.

Use Cases

As a lab author, you can use networks to create realistic networking scenarios:

• Multi-Tier Applications: Separate web, application, and database tiers on different networks to demonstrate network security and architecture patterns
• Complex Network Topologies: Simulate real-world network scenarios including multiple cloud providers, network segments, and federated networks
• Service Discovery: Show users how containers find each other using DNS names and aliases within networks

Networks enable you to create complex, production-like environments where users learn networking concepts through hands-on experience.

HCL Syntax

Basic Syntax

resource "network" "name" {
  subnet = "10.0.0.0/24"
}

Full Syntax

resource "network" "name" {
  subnet      = "10.100.0.0/16"
  enable_ipv6 = true
}

Fields

Field	Required	Type	Description
subnet	✓	string	CIDR subnet for the network (must not overlap other networks)
enable_ipv6		bool	Enable IPv6 support on the network. Defaults to false.

Computed Attributes

These attributes are set by the system after the network is created:

Field	Type	Description
meta.id	string	Unique identifier for the network resource
meta.name	string	Network resource name

Validation Rules

• Subnet format: Must be a valid CIDR notation (e.g., “10.0.0.0/24”)
• No overlap: Subnets must not overlap with other networks in the same lab or host networks
• Valid ranges: Use private IP ranges (10.x.x.x/8, 172.16-31.x.x/12, 192.168.x.x/16)
• Network isolation: Containers on different networks cannot communicate by default

Examples

Basic Network

resource "network" "backend" {
  subnet = "10.0.1.0/24"
}

Network with IPv6

resource "network" "frontend" {
  subnet      = "10.0.2.0/24"
  enable_ipv6 = true
}

Multiple Networks

resource "network" "web_tier" {
  subnet = "10.0.10.0/24"
}

resource "network" "db_tier" {
  subnet = "10.0.20.0/24"
}

resource "network" "management" {
  subnet = "10.0.30.0/24"
}

Container Network Usage

resource "network" "app_network" {
  subnet = "10.0.100.0/24"
}

resource "container" "web" {
  image {
    name = "nginx:latest"
  }

  network {
    id         = resource.network.app_network.meta.id
    ip_address = "10.0.100.10"
    aliases    = ["web", "frontend"]
  }
}

resource "container" "db" {
  image {
    name = "postgres:13"
  }

  network {
    id         = resource.network.app_network.meta.id
    ip_address = "10.0.100.20"
    aliases    = ["db", "database"]
  }
}

Network Communication

Containers attached to the same network can communicate using:

1. Container names: ping container_name
2. Network aliases: ping alias_name
3. IP addresses: ping 10.0.100.10

## From web container to db container
curl http://db:5432
curl http://database:5432
curl http://10.0.100.20:5432

Best Practices

1. Logical Separation: Use separate networks for different application tiers (web, app, database)
2. Private Subnets: Always use private IP ranges to avoid conflicts
3. Subnet Sizing: Choose appropriate subnet sizes - /24 (254 hosts) is usually sufficient
4. Meaningful Names: Use descriptive network names that indicate their purpose
5. Network Aliases: Use aliases for service discovery instead of hardcoding IP addresses
6. Security: Networks provide isolation - containers on different networks cannot communicate by default

Common Subnet Ranges

Range	CIDR	Hosts	Use Case
Small	/28	14	Small labs with few containers
Medium	/24	254	Most common choice for lab environments
Large	/20	4094	Complex labs with many containers
Very Large	/16	65534	Multi-network labs with many subnets