SSL termination refers to the process of terminating the encrypted connection at the load balancer and handling all internal traffic in an unencrypted way. This means that traffic between your load balancer and internal services (or between internal services) will not be encrypted, so you should make sure your network is secure. If you have your own data center, you can trust your network, otherwise you should set up a VPN so traffic can’t be sniffed.

Terminating SSL at the load balancer has a few advantages:

• Single place responsible of managing encryption and decryption of traffic
• Centralized place to store certificates
• The load balancer can analyze the traffic and take special actions based on this
• The load balancer can modify the request and response if necessary

A somewhat common scenario of wanting the load balancer to modify the request is adding headers to HTTP requests. More specifically, it is common to have the load balancer add a X-Forwarded-For header, which includes the IP address where the request originated. Without this header, all requests would look like they originated in the load balancer.

This blog and a few other of my personal projects are not using HTTPS at the moment of this writing. Using plain HTTP has a couple of disadvantages that could result in catastrophic consequences:

• Traffic can be sniffed – If somebody monitored the traffic in your network they would be able the see everything you are sending and receiving (including usernames and passwords).
• Traffic can be modified – When using plain HTTP, there is no guarantee that who you are talking to is who they say they are. Because of this, somebody could intercept your traffic and give you a response of their own. They could give you a log-in form to trick you into entering your credentials

I was trying to do some tuning on my servers network, but while I was at that I realized I couldn’t do it because I didn’t know anything about how Docker does networking. Since I need to move forward with my network configuration, I’m writing this article in the hope of understanding it better.

There are three networks automatically created by the Docker daemon when it starts: bridge, host and none. In this article I’m going to cover the bridge network since it is the default and most flexible one. You can see the networks using docker network ls:

1
2
3
4
NETWORK ID          NAME                DRIVER
d8a90e633c4a        bridge              bridge
b342b31dab76        host                host
48ac37e62c31        none                null

You will also see the bridge network interface created by Docker when running ifconfig:

1
2
3
4
5
6
7
8
docker0   Link encap:Ethernet  HWaddr 05:42:37:b5:36:7a
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:47ff:feb5:867a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:221192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:199761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:69251108 (69.2 MB)  TX bytes:205171116 (205.1 MB)

Lately I’ve been working on a system that has a lot of big tables (with a lot of columns), and often I want to do something like:

1
SELECT * FROM users WHERE id = 1;

But there are so many columns that it doesn’t look good on a terminal:

1
2
3
4
5
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+
| id | username          | created_at          | updated_at          | issuer              | issuer_id             | points | email                               | picture_url                                                                                        |
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+
|  1 | carlos            | 2016-01-31 13:03:36 | 2016-11-04 18:15:56 | accounts.google.com | 111394444444498347111 |    100 | NULL                                | https://lh4.googleusercontent.com/-laaaaaajmcc/AAAAAAAAAAA/AAAAAAAAAAA/qwertyuioaa/s96-c/photo.jpg |
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+

I’m working on a Rails project at the moment, and being new to the Ruby ecosystem I decided to learn a little about Bundler, a framework for managing your project dependencies (similar to npm, composer or pip).

You can install Bundler with the gem command:

1
gem install bundler

This will make the bundle command available on your system.

As with other dependency management systems it all starts by creating a file where you specify your dependencies. The file Bundler looks for by default is Gemfile.

The Gemfile must specify at least one source where the gems will be downloaded from:

1
source 'https://rubygems.org'

Gems are Ruby’s way of packaging applications or libraries so they can be easily shared. https://rubygems.org/ is a place where people host their gems to make them publicly available.

Installing a gem from https://rubygems.org/ is very easy:

1
gem install awesome_print

Once you install the gem, you might want to know where it was installed. You can find some information about your gem install by using gem env:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 2.0.14.1
  - RUBY VERSION: 2.0.0 (2015-12-16 patchlevel 648) [universal.x86_64-darwin15]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/2.0.0
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-15
  - GEM PATHS:
     - /Library/Ruby/Gems/2.0.0
     - /Users/adrian/.gem/ruby/2.0.0
     - /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/gems/2.0.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/

Since I discovered the web I believed it was the future. It gives everyone freedom to create the content they want to create and everybody can consume it no matter what operating system they are running. As technology moved forward, smartphones came to be. Smartphones are awesome, but with it came some regression. The creators of the platforms encouraged developers to create applications that only run on their platforms by offering an interface that was only available if you developed natively.

Browsers caught up pretty fast and came up with APIs for some of the most important features native apps provide (location, sensors, etc…). But there is still something about native apps that makes them somewhat better…engagement. It is not the same to have to open a browser and type a URL than to click an icon on your phone’s home screen.

Last weekend I participated in a hack day with some colleagues and one of them decided that it would be a good idea to use MongoDB. Since I had never used it, I thought it would be fun to learn a little about it. Here I’m going to write about the things that I learned.

Installation

I chose to use Docker because it makes everything easier. The only thing to keep in mind when using Docker for a database is that you need to store the data files outside the container so they don’t disappear when the container is destroyed. This is enough to get the MongoDB running in a container and making sure the data is persisted in $(PWD)/data in the host:

1
docker run --name my-mongo -v $(PWD)/data:/data/db -d mongo:3.3

First steps

Once we have mongo running we need to open a shell in the running container so we can play with it:

Vagrant is a tool for easily creating shareable development environments for your team. It consists of a configuration file with instructions for creating a virtual machine. This virtual machine should contain everything a developer might need to work in a specific project. This configuration file is then committed to the repo and shared with the team. All developers work inside this machine, preventing problems or inconsistencies setting up their development environment.

Now-a-days the same thing can be achieved using Docker(and it is my preferred way of doing it), but the company where I work has some projects using Vagrant, so I decided to learn about it.

Installation

The installation is pretty straight forward. Just head to Vagrant’s downloads page, get the binary for your OS and install it.

I have a digital ocean machine that runs a lonely server on it. This server is just a hobby project so I can afford it to go down every now and then. Nevertheless I want to minimize the time it goes down and be able to identify the cause when it happens.

My initial effort in this direction will be to setup some monitoring on the machine that runs my server. More specifically, I want to see the memory, network, disk, and CPU utilization of the machine graphed over time. This doesn’t solve all my problems but is a first step into getting more insight into what is happening in my server’s environment.