Network

Defined insandbox.hcl

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	Type	Required	Description
subnet	string	✓	Set the IPv4 subnet in CIDR notation, for example 10.100.100.0/24. It must not overlap with any existing network ranges. Containers on this network get addresses from this range. ConstraintsMust be a valid CIDR notation (e.g., 10.0.0.0/24)
enable_ipv6	bool	—	Add an IPv6 range to this network so containers can receive IPv6 addresses. Leave off if you only need IPv4. Defaultfalse

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