Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feat] Easy setup for Postgre on Linux with Docker #2

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -2,3 +2,6 @@
**/*.rs.bk
.idea
config.toml

# Remove Secrets
secrets/
14 changes: 14 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# This is dev version to make the Cargo builds fast and should re-build and run the whole
# app everytime the container is restarted, as Rust doesn't has a proper way of hot reloading
FROM rust:latest
phoenisx marked this conversation as resolved.
Show resolved Hide resolved

WORKDIR /app/spam-watch-api

VOLUME ./ /app/spam-watch-api

phoenisx marked this conversation as resolved.
Show resolved Hide resolved
# This will cache the library builds, which will ultimately help in
# re-running our apps faster.
RUN cargo build

CMD ["cargo", "run"]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you have two Dockerfiles?

Copy link
Contributor Author

@phoenisx phoenisx Oct 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, to separate out deployment logics for production and dev builds. Having two separate ways of deployment, helps you manage separate concerns. For eg, in production build, you can remove the source code (atleast for Rust, as you will get a compiled binary, to reduce the docker image size), that got copied earlier.

Also, it helps to keep different rust versions, till the dev is properly tested and can be deployed to Production.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also check this - https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150
where release build can be a lot more slower to compile.

Copy link

@robbyoconnor robbyoconnor Oct 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure I like it... there has to be a cleaner way to do this...make an env var or something and a script?

Copy link
Contributor Author

@phoenisx phoenisx Oct 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can understand your concern, and keeping things DRY, but if docker commands varies (like for dev and prod), we need separate Dockerfiles, as they are supposed to be pre-built and cached in the hub, with different tags.

Not sure if env vars can be used in images (as in used in Docker Commands), but even if they did, they will make Docker images in-consistent.

What I can think of is, Docker itself acts as an environment specific deployment strategy (just like envs). Each Environment having it's own set of deployment instructions, unless some environments have to be deployed with the exact same build, (like staging/prod can have a single Docker file).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose. Also Dockerfile, NOT DOCKERFILE

14 changes: 14 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# Spam Watch API
phoenisx marked this conversation as resolved.
Show resolved Hide resolved

API server for Spam Watch Bot
phoenisx marked this conversation as resolved.
Show resolved Hide resolved

## Running via Docker

Before running `docker-compose` please make sure you have added:
* Postgres password in `/secrets/.postgre-passwd`
phoenisx marked this conversation as resolved.
Show resolved Hide resolved
* Created `config.toml` from `example.config.toml`.

```
docker-compose up [-d]
```

28 changes: 28 additions & 0 deletions docker-compose.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
version: "3.7"

secrets:
postgres_passwd:
file: ./secrets/.postgres-passwd

services:
postgres:
image: postgres:11.4-alpine
# for production we can remove this exposed ports, as it helps in security
# while debugging for db in prod, should be done via a client container.
ports:
- '5432:5432'
secrets:
- postgres_passwd
environment:
POSTGRES_USER: SpamWatchAPI
POSTGRES_DB: SpamWatchAPI
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_passwd
api:
build:
context: ./
dockerfile: Dockerfile
ports:
- '6345:6345'
volumes:
- ./:/app/spam-watch-api
phoenisx marked this conversation as resolved.
Show resolved Hide resolved

6 changes: 6 additions & 0 deletions example.config.toml
Original file line number Diff line number Diff line change
Expand Up @@ -8,3 +8,9 @@ host = "127.0.0.1"
password = "password"
username = "SpamWatchAPI"
name = "SpamWatchAPI"

[server]
# this is required for docker containers, to be available from
# bridge, for any exposed port
host = "0.0.0.0"
port = 6345
SitiSchu marked this conversation as resolved.
Show resolved Hide resolved