/images/avatar.jpg
DevOps Engineer // Security Enthusiast // Something

OverTheWire Bandit

OverTheWire Bandit is a capture the flag (CTF) game for beginners. I’ve recently regained interest in security and found this a fun way to get back into what originally led me to learn programming. These are quick notes for my solutions on level 0-27.

Level 0 -> Level 1

The password for the next level is stored in a file called readme located in the home directory. Use this password to log into bandit1 using SSH. Whenever you find a password for a level, use SSH (on port 2220) to log into that level and continue the game.

Creating a Docker Workflow with Node.js

Note: These are my findings after working with Docker, Jenkins, and AWS for only 2-3 months. This post details my thought process for the workflow I have set up with Docker and was written to document my progress. However, it might be useful for other beginners who are interested in setting up a better workflow for development with Node.js and Docker.

The Problem

Our development team occasionally has to switch between different projects. Each project has its own set of dependencies requiring a specific version of Node.js, npm, and/or Ruby to be run. Using nvm and rvm can mitigate the issue, but constantly switching between versions is a hassle and it is easy to lose track of which version you’re currently using. Time is also wasted on debugging environment inconsistencies between local development machines, and even more time is lost solving cross-platform issues when deploying to the dev/qa/prod servers (OSX to Linux). Many hours were lost for both the development and system administration teams debugging these issues; hours that could instead be spent improving the current project or working on other projects.

Dockerizing a Node Application

I’ve been hearing good things about Docker ever since I started working professionally as a web developer. However, a lot of the deployment process was abstracted from me. The projects I worked on were mature and had an established workflow. The code I pushed up to Github will end up magically working on the staging server and then to production. A few weeks ago I was given the opportunity see a new project grow through its infancy. I saw a lot of problems with getting a project working locally to work on production. Something would break every few pushes and time would be wasted getting the devleopers and system administrators together to figure out a solution. After hearing so many good things about Docker and how it aims to solve the problems we were having in production, I suggested that we use Docker to develop our application and ship it to production.

Knowing absolutely nothing about Docker, these are the problems I faced and the references I used to figure out a workflow for our developers. This is yet another blog post where I jot down my thoughts and decision making, and not really walking through anything.

Using Capistrano to Deploy Rails App

Docker and Rails in Production

Last week, I deployed a Rails app in a Docker container onto AWS Elastic Beanstalk. It was an unncessarily time consuming task due to small gaps in my knowledge and unfamiliarity with Docker and Elastic Beanstalk. This blog post is written during my first month working as a junior system administrator (“devops”) and this is a recap of my experience to the best of my memory.

Super helpful links: https://github.com/phusion/passenger-docker https://intercityup.com/blog/deploy-rails-app-including-database-configuration-env-vars-assets-using-docker.html https://intercityup.com/blog/how-i-build-a-docker-image-for-my-rails-app.html https://rossfairbanks.com/2015/03/06/rails-app-on-docker-using-passenger-image.html

Thanks to these blog posts (amongst many others), I was able to cut down a lot of time out of learning how to deploy this rails app.

First thing’s first. I installed docker-machine, which is the new boot2docker, and attempted to run my docker image containing the Rails app locally, in production, on my Macbook.