NetBox Deployment to AWS in One Click on

Within the quest for operational excellence at GoodData, discovering a instrument that would present a complete view of our infrastructure was important. My function requires a birds-eye view of our whole infrastructure panorama. That is the place NetBox got here into play — it supplied an environment friendly resolution for DCIM and IPAM, paired with a sturdy API that ticked all the fitting containers for us. Regardless of NetBox’s promise, charting a course for a scalable, production-ready deployment was a enterprise that had but to be totally explored.

The story may have ended right here with the selection of NetBox Cloud, a completely managed service; nevertheless, its expense — surpassing $450 per 30 days — steered the choice towards a self-hosted resolution. Selecting a self-hosted NetBox ensures a easy start-up and cost-saving technique supported by a talented infrastructure group that manages its deployment and maintenance.

The mainstream steering out there pointed towards deployment methodologies that concerned pip or Docker. These are sound beginning factors however not strong sufficient for production-grade deployment. The actual downside lay in scaling as much as a production-ready setup, a subject I discovered conspicuously absent in on-line assets. So, I launched into a mission to bridge this hole, resulting in many experiments and, finally, innovation.

It did not take lengthy for the cloud’s potential to shine by means of. I conceived a blueprint that intertwined AWS providers and Terraform to assist a high-performance NetBox setup. The plan was easy but elegant: ECS for the NetBox container, RDS for PostgreSQL, ElastiCache for Redis, and ELB for load balancing — all managed and deployed utilizing Terraform, our instrument of selection for infrastructure as code.

Word to Readers: The instance I’ll current here’s a single-zone, single-point-of-failure (SPOF) setup supposed to display the fundamental deployment of NetBox on AWS. Whereas it doesn’t cowl monitoring, alerting, or a multi-zone excessive availability (HA) configuration, AWS providers corresponding to RDS and ElastiCache assist scaling and HA. As such, this text serves as a foundational blueprint. You are inspired to construct upon this instance to create a resilient HA setup tailor-made to your group’s wants.

Within the following article, I am going to take you thru a Terraform strategy that establishes a completely operational NetBox surroundings on AWS, step-by-step.

The Blueprint

The structure diagram above represents the top state of what we shall be constructing. It’s a completely managed, extremely out there (if configured that approach) NetBox deployment on AWS. Every AWS service has a task to play on this structure:

• VPC: The foundational community inside which all assets reside.
• RDS: The managed relational database service internet hosting the NetBox database.
• ElastiCache: The managed caching service to hurry up NetBox operations.
• ACM: The AWS Certificates Supervisor manages SSL certificates for safe communications.
• ALB: The Utility Load Balancer distributes incoming software visitors.
• ECS: The Elastic Container Service hosts our NetBox Docker containers.
• S3: The Easy Storage Service shops user-uploaded media recordsdata in NetBox.

For the scope of this text, we’ll exclude S3 and ACM to keep away from further complexity associated to area verification and chronic storage, which aren’t important for preliminary setup.

The Deployment

Conditions

Earlier than we dive into the step-by-step information for deploying NetBox on AWS with Terraform, making certain that you’ve the fitting basis is essential. This part outlines the data and instruments you’ll must efficiently observe together with the article and execute the offered code.

Technical Toolset

AWS Account: An energetic AWS account with ample permissions to create and handle VPCs, ECS clusters, RDS situations, ElastiCache clusters, and different associated providers.

AWS CLI: The AWS Command Line Interface ought to be put in and configured on your AWS account to work together with AWS providers out of your terminal.

Terraform: It’s essential to have Terraform put in and configured in your native machine. Familiarity with writing and making use of Terraform configurations is a prerequisite.

Containerization Information: Understanding Docker containers is useful since NetBox shall be deployed as a containerized software on ECS.

Code Editor: A dependable code editor (like Visible Studio Code, Atom, and so on.) to edit Terraform recordsdata and probably assessment JSON or YAML configurations.

Administrative Issues

AWS Permissions: Make sure that your AWS consumer account has the mandatory permissions to create and handle the assets that Terraform shall be provisioning.

Billing Consciousness: Familiarize your self with the price construction of AWS providers to keep away from sudden prices. Use the AWS Pricing Calculator if wanted.

On this article, the prices will roughly be as follows (month-to-month):

• RDS (PostgreSQL): $11.68
• Storage (for RDS): $2.30
• ALB (Load Balancer): $19.71
• ElastiCache (Redis): $11.68
• Fargate (NetBox): $28.84
• Secrets and techniques: $0.80

The estimated month-to-month price for constantly operating this setup is roughly $75. Nevertheless, providers just like the Load Balancer, RDS, and ElastiCache could serve a number of elements of your infrastructure, permitting for cost-sharing prospects. Moreover, investing in a Compute Financial savings Plan may considerably cut back your bills on Fargate — probably by as much as 51% for a 3-year dedication paid upfront within the us-east-1 area.

By making certain you are outfitted with the data and instruments talked about above, you may be arrange for achievement in deploying NetBox to AWS utilizing Terraform. Now, let’s get able to harness the ability of infrastructure as code to streamline your community administration!

VPC

Our NetBox deployment shall be anchored inside an Amazon VPC, creating a non-public community house for our assets on AWS. This VPC types the bedrock of our NetBox infrastructure, offering a safe, remoted surroundings. It is a key part in guaranteeing that our setup is primed for operational effectivity and scalability. Whereas we begin with a configuration optimized for simplicity and ease of deployment, the VPC is designed to assist future development right into a extra advanced, high-availability community setup.

module "vpc" {
  supply  = "terraform-aws-modules/vpc/aws"
  model = "~> 5.1"

  identify                = "netbox"
  cidr                = "10.254.0.0/24"
  azs                 = ["us-east-1a", "us-east-1b"]
  private_subnets     = ["10.254.0.0/27", "10.254.0.32/27"]
  public_subnets      = ["10.254.0.64/27", "10.254.0.96/27"]
  elasticache_subnets = ["10.254.0.128/27", "10.254.0.160/27"]
  database_subnets    = ["10.254.0.192/27", "10.254.0.224/27"]

  single_nat_gateway = true

  default_security_group_ingress = [{ self = true }]
  default_security_group_egress = [{ self = true }]
}

This Terraform module will initialize a devoted NetBox VPC, together with two availability zones, and proceed to arrange NAT and Web gateways. It can additionally meticulously configure an array of subnets, set up route tables for efficient community visitors administration, and implement safety group guidelines to manipulate the default safety group, making a foundational community infrastructure tailor-made for the NetBox deployment.

The default safety group in our single-purpose VPC is configured to allow all inside visitors, streamlining connectivity for the assets that shall be subsequently deployed inside it. Given the VPC’s singular focus, stringent safety measures are much less important, permitting for a extra open community surroundings that facilitates ease of setup and operation.

Choosing a single NAT gateway in our VPC setup gives a cost-efficient option to allow outbound web entry for personal subnets with out the complexity of a number of gateways.

Whereas the VPC is provisioned with multi-AZ assist, this does not mirror a right away software of excessive availability for NetBox however relatively complies with AWS’s necessities for ElastiCache and RDS, which necessitate multi-AZ configurations even when they don’t seem to be initially utilized in a extremely out there method. This strategy supplies a foundational setup accommodating scalability and future enhancements towards a completely resilient infrastructure.

PostgreSQL (RDS)

Amazon RDS will function the information storage resolution for NetBox, catering to its PostgreSQL wants. RDS streamlines database administration, automating routine duties like patching, backups, and restoration whereas being constructed for straightforward scaling. It is vital for making certain knowledge integrity and availability in NetBox. Initially set with a single occasion, RDS is provided to scale and might transition to a multi-zone setup for enhanced availability in step with evolving necessities.

We may also generate a consumer password with Terraform relatively than counting on RDS to do so¹ or utilizing IAM authentication².

¹ RDS managed password shall be mechanically rotated weekly, however we now have no easy approach of notifying NetBox containers about that out of the field.

² NetBox docker picture doesn’t have a configuration choice to make use of IAM authentication because it requires fetching new credentials often and re-establishing the connection. This could undoubtedly be the best choice as it’s passwordless.

module "db_password" {
  supply  = "terraform-aws-modules/secrets-manager/aws"
  model = "~> 1.1"   

  name_prefix = "netbox-db-password-"

  create_random_password           = true
  random_password_override_special = ""
}

knowledge "aws_secretsmanager_secret_version" "db_password" {
  secret_id  = module.db_password.secret_id
  version_id = module.db_password.secret_version_id
}

module "db" {
  supply  = "terraform-aws-modules/rds/aws"
  model = "~> 6.2"

  identifier = "netbox"

  engine            = "postgres"
  household            = "postgres15"
  instance_class    = "db.t4g.micro"
  storage_type      = "gp3"
  allocated_storage = 20

  availability_zone  = module.vpc.azs[0]

  username                            = "netbox"
  password                            = knowledge.aws_secretsmanager_secret_version.db_password.secret_string
  db_name                             = "netbox"
  manage_master_user_password         = false
  iam_database_authentication_enabled = false

  skip_final_snapshot    = true
  create_db_option_group = false

  parameters = [
    {
      name  = "rds.force_ssl"
      value = "0" # Netbox in App mode can't access /root/.postgresql/postgresql.crt so it disables SSL
    },
  ]

  db_subnet_group_name   = module.vpc.database_subnet_group
  vpc_security_group_ids = [module.vpc.default_security_group_id]
}

The configuration pragmatically bypasses the creation of a closing snapshot and an choice group, indicating a setup extra suited to improvement or testing environments the place instant knowledge persistence will not be important.

Word: Disabling SSL enforcement was wanted because of the bug within the NetBox Docker picture.

Redis (ElastiCache)

Amazon ElastiCache, leveraging Redis, shall be carried out to deal with NetBox’s caching and queuing wants. Important for the applying’s efficiency, ElastiCache is a key part, not simply an improve, offering quick knowledge processing and entry. Starting with a fundamental configuration, ElastiCache is designed to scale and defend knowledge as calls for enhance.

useful resource "aws_elasticache_cluster" "redis" {
  cluster_id           = "netbox"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  parameter_group_name = "default.redis7"

  availability_zone  = module.vpc.azs[0]

  subnet_group_name  = module.vpc.elasticache_subnet_group_name
  security_group_ids = [module.vpc.default_security_group_id]
}

Load balancer (ALB)

Our NetBox deployment technique consists of an Utility Load Balancer (ALB) inside AWS to route incoming visitors to our containerized NetBox situations effectively. This setup enhances reliability and efficiency and types a scalable spine for our community infrastructure. Initially, whereas we have not arrange SSL/TLS termination, the ALB is poised to deal with safe visitors, permitting for encrypted communication integration when obligatory.

module "lb" {
  supply  = "terraform-aws-modules/alb/aws"
  model = "~> 9.0"

  identify    = "netbox"
  vpc_id  = module.vpc.vpc_id
  subnets = module.vpc.public_subnets

  enable_deletion_protection = false

  security_groups = [module.vpc.default_security_group_id]
  security_group_ingress_rules = {
    "allow-http" = {
      ip_protocol = "tcp"
      cidr_ipv4   = "0.0.0.0/0"
      from_port   = 80
      to_port     = 80
    }
  }

  listeners = {
    http = {
      port     = 80
      protocol = "HTTP"

      ahead = {
        target_group_key = "netbox"
      }
    }
  }

  target_groups = {
    netbox = {
      create_attachment = false
      target_type       = "ip"
      backend_protocol  = "HTTP"
      backend_port      = 80
    }
  }
}

NetBox (ECS)

We selected Amazon Elastic Container Service (ECS) with AWS Fargate to run our NetBox software, initially utilizing a single-container mannequin that prioritizes simplicity and ease of upkeep. Whereas our present system would not incorporate Excessive Availability (HA), it is designed with adaptability in thoughts. The combination with a load balancer ensures zero-downtime deployments as a result of ECS introduces new container situations earlier than gracefully retiring the outdated, enabling seamless updates with out service interruption, which units the stage for scaling as much as a sturdy HA configuration sooner or later.

module "secret_key" {
  supply  = "terraform-aws-modules/secrets-manager/aws"
  model = "~> 1.1"

  name_prefix = "netbox-secret-key-"

  create_random_password           = true
  random_password_override_special = "!@#$%^&*(-_=+)"
  random_password_length           = 50
}

module "ecs_cluster" {
  supply  = "terraform-aws-modules/ecs/aws//modules/cluster"
  model = "~> 5.2"

  cluster_name = "netbox"

  cloudwatch_log_group_retention_in_days = 1
}

locals {
  nb_version = "v3.6.4-2.7.0"
}

module "app" {
  supply  = "terraform-aws-modules/ecs/aws//modules/service"
  model = "~> 5.2"

  cluster_arn = module.ecs_cluster.arn
  identify        = "netbox"

  runtime_platform = {
    operating_system_family = "LINUX"
    cpu_architecture        = "ARM64"
  }
  assign_public_ip   = true
  enable_autoscaling = false
  security_group_ids = [module.vpc.default_security_group_id]
  security_group_rules = {
    "allow-internet" = { # to fetch picture
        sort        = "egress"
        protocol    = "all"
        cidr_blocks = ["0.0.0.0/0"]
        from_port   = 0
        to_port     = 0
    }
  }
  subnet_ids = [module.vpc.public_subnets[0]]
  container_definitions = {
    netbox = {
      readonly_root_filesystem = false
      important                 = true
      picture                     = "docker.io/netboxcommunity/netbox:${native.nb_version}"
      port_mappings = [
        { name = "http", containerPort = 8080, protocol = "tcp" },
      ]
      surroundings = [
        {
          name = "DB_HOST"
          value = module.db.db_instance_address
        },
        {
          name = "DB_USER"
          value = "netbox"
        },
        {
          name = "DB_NAME"
          value = "netbox"
        },
        {
          name = "REDIS_HOST"
          value = aws_elasticache_cluster.redis.cache_nodes[0].handle
        },
      ]
      secrets and techniques = [
        {
          name = "DB_PASSWORD"
          valueFrom = module.db_password.secret_arn
        },
        {
          name = "SECRET_KEY"
          valueFrom = module.secret_key.secret_arn
        },
      ]
    }
  }
  load_balancer = {
    service = {
      container_name   = "netbox"
      container_port   = 8080
      target_group_arn = module.lb.target_groups["netbox"].arn
    }
  }
}

Bringing It All Collectively: Execution and Launch

This part guides you thru the ultimate steps of mixing all of the parts — VPC, RDS, ElastiCache, ALB, ECS — right into a cohesive deployment course of. It is the crescendo of the information, the place the execution of Terraform scripts brings the structure to life.

Create a brand new folder and principal.tf file with the next code:

terraform {
  required_providers {
    aws = {
      supply  = "hashicorp/aws"
      model = "~> 5.24"
    }
  }
}

# All of the code from earlier sections
# …

output "lb_dns_name" {
  worth = module.lb.dns_name
}

Export your AWS credentials, run terraform apply, wait till all assets are deployed, and at last, run terraform output lb_dns_name to get a URL to entry your copy of the NetBox.

Merely open it in your favourite browser and use the admin username (the password is identical: admin).

Later, if and while you need to clear it up, merely run terraform destroy, and the whole lot beforehand created shall be deleted.

Subsequent Steps

For companies exploring strong DCIM and IPAM options, this information paves the way in which for seamless integration of NetBox utilizing the cloud’s expansive capabilities. Embrace this Terraform-facilitated pathway on AWS to raise your community administration, remodeling a once-complex endeavor into an environment friendly, scalable infrastructure technique.

Whereas this text lays a strong basis for deploying NetBox on AWS, it is just the start. The present setup, although but to be high-availability, gives a blueprint that your organization can construct upon and customise. It is an preliminary step towards a extra resilient and fail-safe surroundings, offering the groundwork for future enhancement and growth as your infrastructure wants evolve. It’s essential to grasp that this information would not cowl a setup that is meant to deal with hundreds of thousands of requests per second or present the type of robustness a fully-fledged cloud service would provide; it’s a elementary start line, a really perfect inspiration for crafting a sturdy manufacturing resolution tailor-made to your particular operational calls for.

Attain out through the GoodData neighborhood Slack channel together with your feedback and insights. Your suggestions enriches this dialog and sparks innovation and enhancements that profit us all. If there are explicit elements you’d prefer to delve deeper into or further configurations you’re interested by, do not hesitate to tell us.