Eugene Cheah for Uilicious

Posted on Feb 22, 2019 • Edited on Aug 23, 2019 • Originally published at uilicious.com

Launch your own dev.to 🐳 server - with a single command (almost)!

#showdev #docker #opensource #meta

(Disclaimer bash script has only been tested on Ubuntu / MacOS with docker)

Clone the repository, execute the bash script, and follow its on screen instructions.

git clone https://github.com/uilicious/dev.to-docker.git && \
cd dev.to-docker && sudo ./docker-run.sh INTERACTIVE-DEMO

Longer docker based commands (no git clone)

Note: You will need replace all the various <values>

# Run a postgres server configured for dev.to
docker run -d --name dev-to-postgres \
    -e POSTGRES_PASSWORD=devto \
    -e POSTGRES_USER=devto \
    -e POSTGRES_DB=PracticalDeveloper_development \
    -v "<POSTGRES_DATA>:/var/lib/postgresql/data" \
    postgres:10.7-alpine;

# Wait about 30 seconds, to give the postgres container time to start
sleep 30

#
# Run the prebuilt dev.to container
# binded to localhost:3000
#
# Algoliasearch API key is required for dev.to,
# for login do consider adding github/twitter keys as well
# see : https://github.com/thepracticaldev/dev.to/blob/master/config/sample_application.yml
#
docker run -d -p 3000:3000 \
    --name dev-to-app \
    --link dev-to-postgres:db \
    -v "<DEVTO_UPLOAD_DIR>:/usr/src/app/public/uploads/" \
    -e ALGOLIASEARCH_APPLICATION_ID=<APP_ID> \
    -e ALGOLIASEARCH_SEARCH_ONLY_KEY=<SEARH_KEY> \
    -e ALGOLIASEARCH_API_KEY=<ADMIN_KEY> \
    uilicious/dev.to

#
# Also : do give 5~10 minutes for the server to be up. 
# It does take a long time to setup and start
#

Docker hub link : https://hub.docker.com/r/uilicious/dev.to

Dev.to on localhost:3000 example — Btw: I am very amused, by the various random article titles generated on a new deployment

Feature : docker-run.sh script + docker container build #1844

PicoCreator posted on Feb 22, 2019

What type of PR is this? (check all applicable)

[ ] Refactor
[x] Feature
[ ] Bug Fix
[ ] Documentation Update

Description

A single bash script that helps quickly setup either a DEV or DEMO environment

bash-3.2$ ./docker-run.sh

#---
#
# This script will perform the following steps ... 
#
# 1) Stop and remove any docker container with the name 'dev-to-postgres' and 'dev-to'
# 2) Reset any storage directories if RUN_MODE starts with 'RESET-'
# 3) Build the dev.to docker image, with the name of 'dev-to:dev' or 'dev-to:demo'
# 4) Deploy the postgres container, mounting '_docker-storage/postgres' with the name 'dev-to-postgres'
# 5) Deploy the dev-to container, with the name of 'dev-to-app', and sets up its port to 3000
#
# To run this script properly, execute with the following (inside the dev.to repository folder)...
# './docker-run.sh [RUN_MODE] [Additional docker envrionment arguments]'
#
# Alternatively to run this script in 'interactive mode' simply run
# './docker-run.sh INTERACTIVE-DEMO'
#
#---
#---
#
# RUN_MODE can either be the following
#
# - 'DEV'  : Start up the container into bash, with a quick start guide
# - 'DEMO' : Start up the container, and run dev.to (requries ALGOLIA environment variables)
# - 'RESET-DEV'   : Resets postgresql and upload data directory for a clean deployment, before running as DEV mode
# - 'RESET-DEMO'  : Resets postgresql and upload data directory for a clean deployment, before running as DEMO mode
# - 'INTERACTIVE-DEMO' : Runs this script in 'interactive' mode to setup the 'DEMO'
#
# So for example to run a development container in bash its simply
# './docker-run.sh DEV'
#
# To run a simple demo, with some dummy data (replace <?> with the actual keys)
# './docker-run.sh DEMO -e ALGOLIASEARCH_APPLICATION_ID=<?> -e ALGOLIASEARCH_SEARCH_ONLY_KEY=<?> -e ALGOLIASEARCH_API_KEY=<?>'
#
# Finally to run a working demo, you will need to provide either...
# './docker-run.sh .... -e GITHUB_KEY=<?> -e GITHUB_SECRET=<?> -e GITHUB_TOKEN=<?>
#
# And / Or ...
# './docker-run.sh .... -e TWITTER_ACCESS_TOKEN=<?> -e TWITTER_ACCESS_TOKEN_SECRET=<?> -e TWITTER_KEY=<?> -e TWITTER_SECRET=<?>
#
# Note that all of this can also be configured via ENVIRONMENT variables prior to running the script
#
#---

And does the deployment using docker. Includes option to do a reset prior to deployment.

Optional contextual information provided here : https://dev.to/uilicious/adopt-your-own-devto----with-a-single-command-almost-1c04

Need advice on ...

if someone can guide me on how to run dev.to in "Production" mode, it would be great in improving the overall docker container performance

Added to documentation?

sample readme for docker hub : https://github.com/uilicious/dev.to-docker/blob/feature/docker-run-script/dockerhub-readme.md
https://cloud.docker.com/u/uilicious/repository/docker/uilicious/dev.to
I can modify readme if this looks good?

What gif best describes this PR

What gif best describes how it makes you feel?

View on GitHub

PS: if someone can guide me on how to run dev.to in "Production" mode, it would be great in improving the overall docker container performance, in such a setup.

Why do this? Isn't it possible to setup the server using the official readme ??

Well it started out with that, and ...

Its not a problem specifically about dev.to, its simply me being not a ruby developer.

All I wanted was to simply spin up a quick server, so that I can try writing some UI test scripts on it (more on that later).

I really didn't want to be figuring out how to install ruby, sorting out missing os dependencies, and fix my npm versions, trying to figure out why the existing docker build have missing images, etc, etc.......

And in the middle of fixing all that, a flashback on @ben's article from the past hit me ...

For this future where dev.to grows into a series of decentralised dev.to.like networks operated by the community to happen. We need the site to be something that is quick, and easy to deploy for anyone.

Not just someone who "needs" to know how to ruby, postgres, nodejs, or even docker and docker compose for that matter...

We already have hundreds of other more human hurdles in place to get a software adopted...

And in my subjective experience, the ability to get quick one liner demo up and running goes a long way in convincing others... Less is truly more here...

Convincing others in going beyond using https://dev.to/ itself, but to use its open source codebase, perhaps adapt it to their own needs, or more importantly contribute to it!

For homebrew users, think of how many times have you used this one line for yourself or others

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

It helps right?

The current script might not yet be there (for example we could auto install docker if its not present, and maybe in the future break the hard reliance on Algolia). But its one more step into that direction.

So what were you saying about UI testing?

What I work on in uilicious, is to run test scripts like these

// Lets go to dev.to
I.goTo("https://dev.to")

// Fill up search
I.fill("Search", "uilicious")
I.pressEnter()

// I should see myself or my co-founder
I.see("Shi Ling")
I.see("Eugene Cheah")

And churn out sharable test result

Like the above.

However there is one huge problem with it, that I am trying to solve for UI testing in general (not just for Uilicious)...

Which is getting everyone ... To run UI tests as soon as its committed - just like how we run unit tests. (be it uilicious as a development company, its customers, or any dev in general)

Because unfortunately, from what I see - majority of our users on our platform, is testing only on production. With slightly less then half having a testing/staging server. And finally, a very very small fraction testing on a git push.

In development, the earlier a test fails and notifies a developer, the better it is for everyone.

And typically the biggest hurdle in reaching there, is not just getting automated UI tests, but ...

Can you make a build in one step? : If the process takes any more than one step, it is prone to errors
~ over simplifying Joel Spolsky

Or more specifically, can you build, deploy, and test in one step?

Hence it is my small hope, that by making dev.to easier to build and run.

All I need to do next (@todo in next article), is to chain it together with travis for temporary deployments. And finally a process where I can run UI test scripts with git pushes.

Allowing it to serve as an example use case for other dev in doing full UI testing on specific git pushes....

And maybe, maybe perhaps, convince the dev.to team to sign up for our product. or free trial 😉