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 thought…little 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
# a bunch of stuff Ubuntu adds to remind you this file
# is auto-generated and might wipe your changes if you
# save them here
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:
- 184.108.40.206 is the primary private IP on this imaginary instance
- 220.127.116.11 is the first additional private IP on this instance
- 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
- the cloud config file might have a different name, but you should only have one or two files max in that directory
- back your shit up before you fuck about with IP’s and network interfaces
- 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
# DISCLAIMER: Fuck shit up at your
# own risk. Back your shit up. Wash
# your hands. Don't be a dick.
# surprise, motherfucker! this is the same as the one above
# you need to list every private IP address
# that you want netplan to recognize here
# and so on...
# now for the real fun...map the routes
- to: 0.0.0.0/0
- to: 18.104.22.168
- to: 22.214.171.124
- from: 126.96.36.199
- from: 188.8.131.52
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.
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)