loading...
Cover image for Launch your own dev.to 🐳 server - with a single command (almost)!
Uilicious

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

picocreator profile image Eugene Cheah Originally published at uilicious.com ・Updated on ・5 min read

(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

Script command 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


Minion minion shouting joy scene

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

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?

What gif best describes this PR

quick demo

What gif best describes how it makes you feel?

how i feel

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 ...

I failed

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

Uilicious Snippet dev.to test

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.

Please do not test in production

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 πŸ˜‰


Oh, one more thing - DEV mode

./docker-run.sh DEV

dev.to dev mode

A single bash script, to help - not just with testing and demos, but hopefully dev too.

A single line command, to setup your entire dev environment from a cloned repository, and straight into bash.

No ruby/npm installation needed.


PS : If anyone have feedback how I can make this build and deploy script better / etc. Do let me know

Happy shipping πŸ––πŸΌπŸš€

Discussion

pic
Editor guide
Collapse
rhymes profile image
rhymes

I see there's a contribution here to be made ehhe

dev.to's Docker support is currently in beta.

It seems like you've improved it ;-)

Collapse
picocreator profile image
Eugene Cheah Author

Yup, and if this looks good - will be glad for any help on the pull request : github.com/thepracticaldev/dev.to/...

=D

Collapse
ben profile image
Ben Halpern

Oh hell to the yes. I haven’t yet given this a close look but I am excited.

Collapse
butonix profile image
Butonix

How to add admin user?

Collapse
picocreator profile image
Eugene Cheah Author

You might need someone from the official team to chime in / you can post it as a question on github : github.com/thepracticaldev/dev.to/...

I been wondering the same question too btw haha

Collapse
maestromac profile image
Mac Siri

Amazing work Eugene πŸ™Œ. I'm going to give this a whirl.

Collapse
akhilnaidu profile image
Akhil Naidu

Can I expect an update of this, or an elaborated guide to replicate this in the newer version?

If you left this project, give me some hints to help myself.