Although we use monolithic architecture, we actually “break down” the application into several parts in production, such as:
Workers (background jobs)
Therefore, when we deploy, it does not mean that all servers will receive the new application. If we deploy to the Web and there are issues, only the Web will be affected. However, some applications may still have problems if they manipulate shared data until it becomes corrupted.
I want to share how I manage multiple library/gem/package updates simultaneously while doing big upgrades. But before we start, it’s important to know why.
Significant upgrades require a more considerable change of files. The number of files you need to change can get out of hand. You may have to replace some code due to the deprecations, or you may have to deploy in multiple stages to avoid breaking the production.
Rails by default comes with connection pooler on the application side but I always wonder what is the difference if we use another connection pooler such as PgBouncer. So, here is some notes on trying to understand some of it.
To try this out, I’m using docker so that I don’t have to install extra application:
$ mkdir conn-poc; cd conn-poc
$ rails new blog --api -T --database=postgresql
$ mkdir bouncer
$ mkdir db
# create docker network so that PgBouncer and PostgreSQL can communicate with eacher other
$ docker network create conn-poc-1-net
# start postgresql
$ cd db
$ docker run --rm \
--net conn-poc-1-net \
--name conn-poc-1-pg \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=postgres \
-e POSTGRES_DB=blog_development \
-v $(pwd):/var/lib/postgresql/data \
-p 6432:5432 \
-it postgres:13.8-alpine
# start pgbouncer
$ cd bouncer
$ docker run --rm \
--net conn-poc-1-net \
--name conn-poc-1-bouncer \
-e DATABASE_URL="postgres://postgres:postgres@conn-poc-1-pg/blog_development" \
-v $(pwd):/etc/pgbouncer \
-p 7432:5432 \
edoburu/pgbouncer
PgBouncer config:
In the previous post, we managed to figure out a way to make our Docker setup work for Development. It’s time to figure out how we can run our tests with it. In the end, we should be able to run single and multiple tests. This also includes Capybara tests using headless Chrome.
We will also look into how to use multiple docker-compose files to override what we have based on the environment. But we’ll start with something simple first.
Check out my previous post if you want to start learning from just a Dockerfile. As you may have realized, it’s not scalable if we keep on using the long command to manage our containers. We haven’t even started talking about different services such as PostgreSQL and Redis, yet.
In this post, we are aiming to use docker-compose to make our development
experience easier.
I’m assuming we are starting from fresh where we don’t have any Ruby on Rails application ready, yet. I’ll put a note later if you are starting with an existing application.