Surprise! Private IP’s Can Move…

The AWS adventures continue…

I’ll keep this short and sweet, because it was almost life-changing and I’m tired of ranting. Something something be more positive something attitude affects everything something something eat a dick.

I noticed, previously, when adding additional private IP’s to an AWS instance, the input field has a placeholder value of Auto-assign. I never gave it much thought until my EC2 instance stopped connecting to the Internet yesterday. Maybe I can write another post on that later. Hours pass. Attempts to fix an issue affecting updates and certbot fail miserably. I rebuild the damn thing this morning; hence the lesson…

I debate and decide to test the merits of a separate standalone Network Interface. I’m certain, out there somewhere, in the deathlike silence and chill of a datacenter, a Sysadmin or DevOps Engineer knows the answer. I’m not that wizard, and the Interface idea fails spectacularly when binding those private IP’s to the EC2 instance. You might think I’d learn to test one or two IP’s instead of rewriting the whole damn netplan file, but apparently you don’t know me. So, the separate Network Interface idea dies in solitary.

At this point, I’m resigned to rewriting the netplan YAML again (that would be the second time in one day). “What the fuck, I might as well try to move these private IP’s and save myself an hour of work after spending 20 hours trying to fix it.”

Lo and behold, it worked. The heavens parted and the networking gods smiled on me. The fact you’re reading this is proof they haven’t shit on me since (at least in this case).

Slaying the Dragon

or “How I Figured the Fucking IP’s Out and Learned to Love netplan

I suppose it’s that time of year again, where I write one of my two annual posts. Some years I only get through one. I actually enjoy writing, I just never seem to find time to do it. Oh, well, as the title implies, and the subject line explicitly states, I finally figured out that pain-in-the-ass (PITA) netplan. If you’re curious where this started, take a look (just don’t forget to come back)!

The problem never changed, I ended up trying to worm myself out of facing this enemy again with a number of t3.nano instances instead of one m5.medium instance. Unfortunately (or so I thoughtlittle did I know…), some of the WordPress and other database-heavy code stubbornly refused to run on a t3.nano. By the time I had eight t3.nanos, four t3.micros, a t2.micro, and a partridge in a pear tree, I opted to switch to a bigger server and put everything on it.

That meant one of two options: learn netplan (shudder) or use Ubuntu 16.04 and go through the joy of Canonical’s lack of support for an old OS (read: having to pull in additional repos to build PHP 7.x). I’ll admit…I started with 16.04. It didn’t take long to piss me off, though, and I “embraced the suck” (as High Overlord Pelosi would like all citizens…er, except Congress…to do).

Much to my surprise, it came way easier this time… (lucky “it”…S/O Rob, Anybody, and Dawn)…

The first thing I had to do (which I could swear I tried last time) was create a separate YAML file for storing the network data…and call it first (the base file is called 50-cloud-init.yaml, I named mine 01-multi-ips.yaml). Hold up a sec there, cowboy…the first thing I did was build an AMI out of my server so I could spin everything back up if I fucked everything to hell again.

So, technically the second was that new file thing.

I kept the names the default file did.

The Original File

# /etc/netplan/50-cloud-init.yaml

# a bunch of stuff Ubuntu adds to remind you this file
# is auto-generated and might wipe your changes if you
# save them here
network:
version: 2
ethernets:
ens9:
dhcp4: true
match:
macaddress: HA:HA:IM:NO:TR:EA:L0
set-name: ens9

Bright and Shiny (the new config file)

I’m only using a couple IP’s for an example, but I ended up binding whatever the maximum is. But before you take a look, keep a few things in mind:

  1. 172.172.172.1 is the primary private IP on this imaginary instance
  2. 172.170.180.3 is the first additional private IP on this instance
  3. ens9 is the name of the network device from the previous file; you might see a different name, and if you do, use the name you see in your cloud config file
  4. the cloud config file might have a different name, but you should only have one or two files max in that directory
  5. back your shit up before you fuck about with IP’s and network interfaces
  6. I’m fairly sure this is spaced correctly, but it’s a good idea to get a YAML Linter or otherwise validate your YAML before running the command to kick off the IP update or restarting your server
# /etc/netplan/01-multi-ips.yaml

# DISCLAIMER: Fuck shit up at your
# own risk. Back your shit up. Wash
# your hands. Don't be a dick.

network:
version: 2
renderer: networkd
ethernets:
# surprise, motherfucker! this is the same as the one above
ens9:
# you need to list every private IP address
# that you want netplan to recognize here
addresses:
- 172.172.172.1/20
- 172.170.180.3/20
# and so on...
dhcp4: no
# now for the real fun...map the routes
routes:
- to: 0.0.0.0/0
via: 172.172.172.1
table: 1000
- to: 172.172.172.1
via: 0.0.0.0
table: 1000
- to: 172.170.180.3
via: 0.0.0.0
table: 1000
routing-policy:
- from: 172.172.172.1
- from: 172.170.180.3

I really wish I could explain what everything here is, but I can’t, but the good news is…Google exists…and it’s your friend for finding answers on StackOverflow.

Just one two more steps…

Run sudo netplan apply –debug

I’m a fan of running –debug because it will warn you if something is awry before you fuck your connection to hell. You’ll still have a chance to delete or comment out or rename your monster before things go south.

Finally, bind your Elastic IP’s to your private IP’s and you’ll see things work. ifconfig will not look right (neither will sudo netplan ip leases ens9)