How to Use Floating IPs for Easy Cloud Scaling
Learn how to scale up to a faster droplet without Docker or Kubernetesby Joe Honton
In this episode Ivana teaches herself how to migrate to a more powerful web server without Docker or Kubernetes.
Rocket Science is an after-school STEM program for the teenagers of Rock City. Recently Ivana crafted a new website portal where students and their tutors could remotely access assignments.
Everything worked beautifully. Actually, too beautifully. It was time to get off that introductory-sized droplet from Digital Ocean.
Ivana dreaded the thought of disturbing something that was working. Since she had never faced this before, she asked her teammates for advice.
"Containerization is the answer," declared Devin, the team's Docker guy. "Put everything into a container and you can spin up a new instance anywhere — especially great for testing and staging."
"But I'm done testing," she replied. "Everything's working beautifully. Why do I need to learn how to containerize it?"
"It's really powerful, once you learn how it works," was his only argument.
There were plenty of online guides, so Ivana began looking into it.
"Hmm," she thought, "Choose a base image, install packages, expose ports, handle logging. That's all stuff I've already done on the droplet. I guess I could do it all again.
"But wait," her alarms went off, "Define an entry-point — what? Define a configuration method — really? Externalize your data — yikes!"
In her confusion, Ivana went over to Ken's desk, for a second opinion. "Is Docker really the right answer?" she asked.
"Well, it can be," Ken paused, then added "but if you want best-in-class horizontal scalability then Kubernetes is the answer." Ken was the team's Kubernetes guy.
Ivana wasn't sure what that really meant, so she did some quick research. "Oh, I get it, horizontal scaling is adding servers into a cluster and putting a load balancer on the front."
It was time to quit for the day, and settle into the long commute up Route 85. On her way home, she puzzled over how to proceed.
The following morning, Ivana began looking again at what it would take to get some better performance for the Rocket Science website. Since their cloud provider was Digital Ocean, she was ready to ask for some advice on the DO forum when she stumbled upon an article about floating IPs. Somehow she had missed that one.
A bright idea came to mind. Why not skip all the buzz about containerization, and simply throw hardware at it? She wanted to experiment with this idea.
She got right to it.
9:30 a.m. First, she went to the Digital Ocean networking panel and reserved a floating IP. Then she assigned that floating IP to the droplet hosting the
rocket-science.com website. This took only a couple of minutes to do.
9:32 a.m. Next, she went to the domain panel and changed the existing DNS record for
rocket-science.com to the newly assigned floating IP. Changing the DNS record only took a minute, but waiting for the DNS record to propagate would eventually take about 30 minutes (the domain's TTL record was set at 1800).
9:35 a.m. In the mean time, she texted Michiko at Rocket Science to let her know that the website would be down for a couple of minutes while she did some quick maintenance.
She monitored the progress of DNS propagation by checking a few public DNS servers.
[root@rocksci] nslookup rocket-science.com 184.108.40.206
[root@rocksci] nslookup rocket-science.com 220.127.116.11
[root@rocksci] nslookup rocket-science.com 18.104.22.168
Then she walked over to Starbucks to get her second cup of the day. She crossed paths with Devin and Ken who were deep into some tech soup argument, so she just politely nodded and passed on by.
10:00 a.m. When she returned to her desk twenty-five minutes later, the DNS change had fully propagated. She stopped the HTTP/2 Server and shut down the droplet:
[root@rocksci] systemctl stop rwserve
[root@rocksci] shutdown --powerdown now
10:02 a.m. She took a snapshot of the droplet, while it was shut down, to create an image of the whole server. This took only a few minutes (even though the DO instructions warned that it could take longer depending on how much disk space was being used).
10:06 a.m. As soon as the snapshot was complete, she created a droplet using that image as a base. She chose a Digital Ocean 1GB/3CPU plan located in the same datacenter as the existing 1GB/1CPU droplet. As promised, the droplet was up and running in about a minute.
10:07 a.m. She reassigned the floating IP from the
rocksci droplet to the new
10:08 a.m. She logged into the system and reconfigured the HTTP/2 Server to make use of the new processors. She upped the cluster-size from 1 to 3. Also she had read that instead of listening on the real IP address or the floating IP address, it was more convenient to simply listen on 0.0.0.0. This is what the new config looked like:
10:13 a.m. Everything was ready for the coup de grâce. Would the experiment work? She started up the server.
[root@rocksci2] systemctl start rwserve
10:14 a.m. A quick browser test confirmed that the website was up and running. Her coffee was still hot.
That afternoon, Ivana received a text from Michiko.
"Don't know why" "Kids say portal seems faster" "Tks"
The next morning during their daily stand-up, Clarissa asked, "So, what are we going to do about Rocket Science? Will we need to use Kubernetes, or is Docker going to be enough?"
"Actually, neither. I've already fixed it," announced Ivana.
"Cool," Clarissa exclaimed, before Devin or Ken could say anything, their facial contortions expressing astonishment.
Later on, Clarissa, who is Tangled Web Services' founder, remarked privately to Ivana, "Thanks for fixing things for Michiko. Great work! From the remarks by the other guys I thought we'd be struggling with this for weeks, if not longer."
That night the commute up Route 85 seemed faster than usual.
No minifig characters were harmed in the production of this Tangled Web Services episode.
Follow the adventures of Antoní, Bjørne, Clarissa, Devin, Ernesto, Ivana, Ken and the gang as Tangled Web Services boldly goes where tech has gone before.