3.5 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CTP Topic 45 Automatic IP address allocation with IPAM | cloud-learning | video | DevOps & SRE/08_Networking |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 45_ Automatic IP address allocation with IPAM.mp4 | summarized (Gemini 摘要) |
CTP Topic 45 Automatic IP address allocation with IPAM
Source: NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 45_ Automatic IP address allocation with IPAM.mp4
Type: VIDEO | Category: 08_Networking
Status: 🟡 Awaiting Whisper transcription → Summary
摘要
Automatic IP Address Allocation Using IPAM
IPAM (IP address management) provides the ability to effectively manage, control, monitor, and assign IP address space within a company. It automates IP address management tasks in a centralized and easily accessible manner. Currently, IP addresses are managed in Excel sheets, which is inefficient. Info blocks NIOA appliance provides IPAM functionality as a seamless extension of distributed grid framework, DNS, and DHCP with a unified management console.
The current architecture involves a grid master and various AWS cloud accounts. API calls are made to interact with the grid. Extensible attributes have been defined for cloud usage, including space owner, company, subnet name, compartment type, and status.
The current VPC provisioning approach involves collecting data from the business unit (BU) regarding their IP address needs. The SRE team raises a request to the network team, who calculates the optimal CIDR range and updates a spreadsheet. The SRE team then prepares a YAML file to provision the VPC. Managing the IP address in a spreadsheet takes time and it's not a good approach.
The new approach automates subnet calculation using Infoblox NIOS. If the requested network address is less than 24, the VPC module is run. If it is more than 24, mandatory approval from the network team is required. The key difference is that IP addresses are no longer requested from the network team, and the network.yml file is not prepared manually. NIOS automatically provides the next available IP address.
The new YAML file includes a new info blocks block with business contact, engineering contact, and date. It does not contain CIDR subnet IP addresses. Instead, it specifies the desired subnet size (e.g., /22). A parent cider is included, which is a constant value per region. The VPC name is now included in the YAML file, allowing for multiple VPCs.
The new system is fully automated, querying info box to get the next available block and provision accordingly. It aims to reduce handoffs and provide a single source of truth. The system is backward compatible, meaning existing VPC configurations using the old YAML file will continue to work. The goal is for any new VPC that we don't have to engage the network team every time we want to create a VPC with the subnets.
The implementation also allows for specifying availability zone IDs for subnets. We are not asking for IP address from the network team. The system also supports de-provisioning, where destroying a VPC will remove all entries from the IPAM grid. Safeguards are in place to prevent accidental deletion of VPCs, such as requiring a special flag in Terragrant.htl.
关键概念
行动项
相关视频
配对视频笔记链接（生成后填入）
最后更新: 2026-04-14