Quick connect to your Amazon ec2 linux instance through the command line

Hey There!

Disclaimer: In this blog post my assumption is that you already have an Amazon ec2 instance up and running . I will explain how you can ssh into your instance through the linux command line. This is only for Linux users! 😞 and is based on an Elixir-Phoenix project

This is for you if:

— You are already familiar with the use of Amazon Web Services for instance the Elastic Computing Cloud(ec2).

— You are having trouble propagating your locally made changes to production environment.

— You think everything works fine by testing on the development environment(been there), think again…

What you will need:

— Linux Os,

— Your instance’s .pem file, if you are unfamiliar with this, take a look at creating ec2 key pairs https://amzn.to/2Mm6Hsp

— Your ec2 instance’s name or IP address

— The default username for your Instance’s AMI

• For Amazon Linux 2 or the Amazon Linux AMI, the user name is ec2-user.
• For a Centos AMI, the user name is centos.
• For a Debian AMI, the user name is admin or root.
• For a Fedora AMI, the user name is ec2-user or fedora.
• For a RHEL AMI, the user name is ec2-user or root.
• For a SUSE AMI, the user name is ec2-user or root.
• For an Ubuntu AMI, the user name is ubuntu.

nib build — pull — A pair of hands 😊

Lets Get it Started! 🎶

step 1: Find Your .pem file

Open your Linux Terminal and navigate to the directory where your ec2 .pem file is. In my case it is in the Dropbox folder, inside another Folder named frenet.

step 2: ssh into the instance

Once you are in the folder where your .pem file lives we can ssh into the instance from here. The command syntax goes something like this.

Replace the <> with the actual ones provided in the prerequisites above. Once you do, without an error message, you will be on the terminal of your instance. Exciting ey?

step 3: Navigate to you project directory

At this point you are still not within your project directory. so navigate into the folder where your project lies. In my case, I called it ‘app’.

step 4: I have no idea why I’m telling you this

But as much as at this point, you are at liberty to change your code and use git CLI commands, it is Never recommended to make raw changes in your production server. Any blunders made here will directly be propagated to your production environment. So Don’t do it! I recommend the conventional “Create a pull request” that makes any necessary changes for you.

Another Never: Never run the server as a super user, I did this because I have not yet setup my load balancer

step 5: Setup for production

Once you have made all the necessary changes. You can setup for production using the commands given here:

# Initial setup

$ mix deps.get — only prod

$ MIX_ENV=prod mix compile

# Compile assets

$ cd assets && webpack — mode production && cd ..

$ mix phx.digest

# Custom tasks (like DB migrations)

$ MIX_ENV=prod mix ecto.migrate

You don’t have to run them all every time. If you understand what they do, just run the ones necessary for you at the time.

step 6: Sign in as super user

Whenever we want to run the server to view our changes we need to switch to being a super user, else you get an error message on denied permissions. This is done by the following CLI command:

step 7: Run Phoenix server

Now we are running commands as a super user. But we are in the production environment. This means that all our commands are to be prefixed by MIX_ENV=prod to specify that we are running a certain command on the production environment. So to run our mix server we run the command:

Note that you can also run the server as a background service/daemon using the ‘detached’ flag:

step 8: Specify server port

Lastly we need to specify the port to run on. Since I configured my endpoint to run on port 80, I should also tell my server to run on the same:

Well this is colourful! 😂

step 9: Terminate existing server instance

The :eaddrinuse (address already in use) error shouldn’t scare you much. It only means that there’s already another server running on the same port. So all we do is kill it(sounds harsh) with this command.

step 10: Brag about how hard it was 😄

Then you can rerun your server again and navigate to the provided url. You also need to restart your server for any changes made to reflect.

That’s all there is to it! Remember the reason for discovering this was because I didn’t yet have a CI/CD pipeline that does automated deployment for me. I’ll cover this on another blog.

FYI the AWS docs are so helpful when it comes to this too. Take a look, I probably might have missed out on a thing or two that you are looking for. 🙂

Until next time. Peace !