4.1 KiB
Development
Install instructions in INSTALL.md
Basic commands for development
Load env variables (don't skip this step):
source script/env.sh .env .env.development
Start:
docker-compose up --build development`
Build or rebuild:
docker-compose build`
Debug:
docker attach ensl_development
To get inside docker web+test containers:
docker-compose exec -u root development /bin/bash`
docker-compose exec -u web development /bin/bash`
docker-compose exec -u root test /bin/bash`
docker-compose exec -u web test /bin/bash`
Restart the web container
docker-compose restart web`
Run some tests:
docker-compose exec -u web test bundle exec rspec`
docker-compose exec -u web test bundle exec rspec spec/controllers/shoutmsgs_controller_spec.rb`
Unresolved issues for dev
There are some unresolved issues to setup dev env.
-
Make sure tmp, tmp/sockets, tmp/pids and log exist.
-
Make sure docker has access to its dirs. You might have to chown if you have permission issues with docker.
sudo chown -R 1000:1000 . sudo chown -R 999:999 db/data
-
You might have to run migrations manually.
bundle exec rake db:migrate
Tips
-
If you need to run stuff on your host (eg. ruby, rubocop, bundle install etc) run all commands from the:
Dockerfile.dev
. It should setup identical setup for your machine. -
Add docker container names to /etc/hosts. This makes it possible to run test from local machine without using the container since editor/IDE don't integrate with Docker so well.
sudo echo
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ensl_dev_db
db >> /etc/hosts -
VS Code and RubyMine are great IDE's/editors.
-
To run VS Code plugin Ruby Test Explorer in docker container you need to create path to custom path, copy the formatter and it whines about and it still fails a bit.
-
You can run tests easier if you setup the stuff on your own computer.
-
Do not commit too much without testing. Also keep commits small for documentation and reversability issues.
-
You need to rebuild the docker image when you change gems.
-
To restart NGINX
docker-compose exec nginx nginx -s
-
To restart PUMA
touch tmp/restart.txt
Design of ENSL Application
Read this to understand design decisions and follow them!
- Env variables should be used everywhere and loaded from .env* files using Dotenv
- Load order is in [here]|(https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use)
- Local changes go to .env*local and NOT .env
- Passwords are in ENV variables for now so they don't have to duplicated between DB and Rails.
- Everything should be running on containers.
- Docker-compose is the heart of deployment
- Dockerfile should contain the gems and prebuilt assets for production
- The app contents are added to the docker image on build but it is mounted as volume. It will override the Dockerfile content.
- The public directory contains everything public. NGINX will try to find files there and ask from PUMA if it doesn't.
- The local public directories (images, files, icons, avatars etc.) are to be addeed to .gitignore
- Assets are compiled on-fly in development mode.
- In production/staging etc. assets are precompiled and stored. Entry script can do this.
Tags in code
FIXME, TODO, EXPLAIN, OBSOLETE
TODO issues for dev
- Puma should be running (eg. spring), and if debugger is used it should be able to connect via docker-compose up
- Should directories exist?
- docker-compose has some .env specific vars and then
- The env variables are not always loaded causing mysterious issues.
- How much in env vars?
Best practices
Take a look at these before writing anything.