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
orroot
. - For a Fedora AMI, the user name is
ec2-user
orfedora
. - For a RHEL AMI, the user name is
ec2-user
orroot
. - For a SUSE AMI, the user name is
ec2-user
orroot
. - 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 !