Is It Easy to Move From GCP to AWS?
By: Randal Kamradt Sr
Tags: Docker Compose, Docker, AWS, Google Cloud Platform, Programming

Set Up the New VM

Now we need to open a terminal window and connect to the new VM:

ssh -i ~/.ssh/amazon.pem ubuntu@3.135.240.32

The username ubuntu is the default username for VMs with an Ubuntu image. Yours may be different. When it prompts you about whether this is really the server you’re trying to connect to, say “yes.” You should be in the newly provisioned VM. It should already have Git installed. You can check by running git and seeing if you get the help printout. Docker wasn’t installed on my VM, but running docker gave me a hint on how to install it:

sudo snap install docker

Those are the only things you have to install on your new VM!

One of the most labor-intensive parts of this is copying the configuration files. Because the configuration files contain secrets, they can’t be on GitHub or DockerHub, so they should be somewhere separate. In my case, I keep config files in the directory below where I keep all my GitHub repositories on my laptop. I’m going to copy these files up to the home directory of the new VM. You might think that since they contain sensitive information, you should put them somewhere clever, but if someone hacked into your VM, they’re probably smart enough to find wherever you hid them.

There are two ways to copy them to the VM: Either you can use scp to copy or you can just cat them on your laptop, use vi to create the files in the home directory on your VM, and cut and paste. I used the latter process because I always have trouble remembering the exact syntax of the scp command. There are five files to copy: config.yml , kamradtfamily.net.key , kamradtfamily.net.pem , phpapp.env , and phprest.env . These were all created in my previous articles, so you’ll have to read through them to find out the contents, as I can’t present them here without redacting most of them.

Next, we’re going to get the deployment scripts and public configuration scripts that are in GitHub. This is a simple clone operation — again in the home directory on the VM:

I used the https protocol instead of the ssh protocol since we won’t be updating the repository from the deployment host and don’t want to be bothered with the SSH keys.

This should create a directory called phpappprod . cd to it and then start up the system:

sudo docker-compose up -d

If everything is correct, you should be able to browse the new site at https://phpdemo.kamradtfamily.net/.

If all goes well and you’ve used my code, you’ll get to a login screen. There’s not much you can do with it. If you’ve followed along with my previous articles and set up your Okta service, you’ll be able to log in. When I log in, I get my wine-and-cheese pairing application, and I can tell it’s a new instance because the list is blank.

I can add a pairing and test out the REST read microservice on https://phprest.kamradtfamily.net/api, which should give me the new database record in JSON.

My point here is that by staying close to vanilla VMs, you can transfer your knowledge from one cloud provider to another. I had no experience with AWS before this, yet I was able to deploy an application in an hour.

If you’re an employer looking for a new developer who can deploy to AWS, you just have to look for Docker Compose experience instead of specific AWS experience. If you’re a developer, you can go into a shop and jump right in if they run AWS, GCP, Azure, or some other cloud provider. It’s a good reason to avoid the temptation of utilizing all the gadgets and gizmos of the cloud provider you choose.