New WaitingListEntry #33
|
@ -7,7 +7,6 @@ steps:
|
|||
- name: docker
|
||||
image: plugins/docker
|
||||
environment:
|
||||
DJANGO_ENV: production
|
||||
BUILD: "${DRONE_COMMIT_SHA}"
|
||||
settings:
|
||||
repo: docker.data.coop/membersystem
|
||||
|
@ -17,7 +16,6 @@ steps:
|
|||
password:
|
||||
from_secret: DOCKER_PASSWORD
|
||||
build_args_from_env:
|
||||
- DJANGO_ENV
|
||||
- BUILD
|
||||
tags:
|
||||
- "${DRONE_BUILD_NUMBER}"
|
||||
|
|
|
@ -6,4 +6,3 @@ DATABASE_URL=postgres://postgres:postgres@postgres:5432/postgres
|
|||
# Use something along the the following if you are not using docker
|
||||
# DATABASE_URL=postgres://postgres:postgres@localhost:5432/datacoop_membersystem
|
||||
DEBUG=True
|
||||
DJANGO_ENV=development
|
||||
|
|
16
Dockerfile
16
Dockerfile
|
@ -7,16 +7,12 @@ ENV PYTHONFAULTHANDLER=1 \
|
|||
PIP_NO_CACHE_DIR=off \
|
||||
PIP_DISABLE_PIP_VERSION_CHECK=on \
|
||||
PIP_DEFAULT_TIMEOUT=100
|
||||
ARG DJANGO_ENV
|
||||
ARG BUILD
|
||||
ENV BUILD ${BUILD}
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
RUN groupadd -g 1000 www && useradd -u 1000 -ms /bin/bash -g www www
|
||||
COPY --chown=www:www . .
|
||||
RUN mkdir /app/src/static \
|
||||
&& chown www:www /app/src/static \
|
||||
RUN groupadd -g 1000 www && useradd -u 1000 -ms /bin/bash -g www www \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y \
|
||||
binutils \
|
||||
|
@ -29,8 +25,14 @@ RUN mkdir /app/src/static \
|
|||
libgdk-pixbuf2.0-0 \
|
||||
libffi-dev \
|
||||
shared-mime-info \
|
||||
gettext \
|
||||
&& pip install . \
|
||||
gettext
|
||||
|
||||
COPY --chown=www:www . .
|
||||
|
||||
RUN mkdir /app/src/static \
|
||||
&& chown www:www /app/src/static
|
||||
|
||||
RUN pip install . \
|
||||
&& django-admin compilemessages
|
||||
|
||||
ENTRYPOINT ["./entrypoint.sh"]
|
||||
|
|
26
Makefile
26
Makefile
|
@ -1,6 +1,5 @@
|
|||
DOCKER_COMPOSE = COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose
|
||||
DOCKER_RUN = ${DOCKER_COMPOSE} run -u `id -u`
|
||||
DOCKER_BUILD = DOCKER_BUILDKIT=1 docker build
|
||||
DOCKER_CONTAINER_NAME = backend
|
||||
MANAGE_EXEC = python /app/src/manage.py
|
||||
MANAGE_COMMAND = ${DOCKER_RUN} ${DOCKER_CONTAINER_NAME} ${MANAGE_EXEC}
|
||||
|
@ -10,12 +9,6 @@ init: setup_venv pre_commit_install migrate
|
|||
run:
|
||||
${DOCKER_COMPOSE} up
|
||||
|
||||
setup_venv:
|
||||
rm -rf venv
|
||||
python3.11 -m venv venv;
|
||||
venv/bin/python -m pip install wheel setuptools;
|
||||
venv/bin/python -m pip install pre-commit boto3 pip-tools;
|
||||
|
||||
pre_commit_install:
|
||||
venv/bin/pre-commit install
|
||||
|
||||
|
@ -37,22 +30,5 @@ shell:
|
|||
manage_command:
|
||||
${MANAGE_COMMAND} ${ARGS}
|
||||
|
||||
add_dependency:
|
||||
${DOCKER_RUN} ${DOCKER_CONTAINER_NAME} poetry add --lock ${DEPENDENCY}
|
||||
|
||||
add_dev_dependency:
|
||||
${DOCKER_RUN} ${DOCKER_CONTAINER_NAME} poetry add -D --lock ${DEPENDENCY}
|
||||
|
||||
poetry_lock:
|
||||
${DOCKER_RUN} ${DOCKER_CONTAINER_NAME} poetry lock --no-update
|
||||
|
||||
poetry_command:
|
||||
${DOCKER_RUN} ${DOCKER_CONTAINER_NAME} poetry ${COMMAND}
|
||||
|
||||
build_dev_docker_image: compile_requirements
|
||||
build_dev_docker_image:
|
||||
${DOCKER_COMPOSE} build ${DOCKER_CONTAINER_NAME}
|
||||
|
||||
compile_requirements:
|
||||
./venv/bin/pip-compile --output-file requirements/base.txt requirements/base.in
|
||||
./venv/bin/pip-compile --output-file requirements/test.txt requirements/test.in
|
||||
./venv/bin/pip-compile --output-file requirements/dev.txt requirements/dev.in
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
Copy over the .env.example file to .env and adjust DATABASE_URL accordingly
|
||||
|
||||
$ cp .env.example .env
|
||||
$ cp .env.example .env
|
||||
|
||||
### Docker
|
||||
|
||||
|
@ -56,7 +56,7 @@ Activate the venv
|
|||
|
||||
Install requirements
|
||||
|
||||
$ pip install -r requirements/dev.txt
|
||||
$ pip install .
|
||||
|
||||
Run migrations
|
||||
|
||||
|
|
|
@ -1,5 +1,3 @@
|
|||
version: '3.7'
|
||||
|
||||
services:
|
||||
|
||||
backend:
|
||||
|
@ -13,7 +11,8 @@ services:
|
|||
volumes:
|
||||
- ./:/app/
|
||||
depends_on:
|
||||
- postgres
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
env_file:
|
||||
- .env
|
||||
|
||||
|
@ -25,6 +24,13 @@ services:
|
|||
- 5432:5432
|
||||
env_file:
|
||||
- .env
|
||||
# This healthcheck has a large number of retries, this is currently based on the number of
|
||||
# retries necessary to get the database running in GitHub Actions.
|
||||
healthcheck:
|
||||
test: [ "CMD-SHELL", "pg_isready -U postgres -d postgres" ]
|
||||
interval: 5s
|
||||
timeout: 5s
|
||||
retries: 30
|
||||
benjaoming marked this conversation as resolved
Outdated
|
||||
|
||||
volumes:
|
||||
postgres_data:
|
||||
|
|
|
@ -1,16 +1,5 @@
|
|||
#!/bin/sh
|
||||
|
||||
echo "Waiting for postgres..."
|
||||
|
||||
POSTGRES_PORT=${POSTGRES_PORT:-5432}
|
||||
POSTGRES_HOST=${POSTGRES_HOST:-localhost}
|
||||
|
||||
while ! nc -z "$POSTGRES_HOST" "$POSTGRES_PORT"; do
|
||||
sleep 0.1
|
||||
done
|
||||
|
||||
echo "PostgreSQL started"
|
||||
|
||||
# Only migrate, collectstatic and compilemessages if we are NOT in development
|
||||
if [ -z "$DEBUG" ]; then
|
||||
python src/manage.py migrate;
|
||||
|
|
Loading…
Reference in a new issue
@valberg this is where I added the healthcheck 🤦
Roger - the thing is that this compose file is for development, whereas the one we use for production is placed in https://git.data.coop/data.coop/ansible/src/branch/main/roles/docker/templates/compose-files/membersystem.yml.j2
With the current entrypoint one does not have to keep this health check in mind.
Aaaah, I get that now. This was intended to simplify things, but of course that's not the case when the deployment could benefit from the other method 👍 thanks for explaining! I took this method from a setup where Docker Compose was also for deployment :)
Reverted!
You're welcome! We could put in the work to make it work for both. But since the membersystem is pretty much a single deployment project, I'm unsure of the benefit of doing said work 😊
I think the main priority should be that all our data.coop services are somehow deployed in the same/similar way... but then their development environment can be allowed to drift.
Reasoning would be that we could have many people doing deployment/ops, and they should be required minimal familiarity with each project that we deploy?
So in this case, I think your choice was 💯 - i.e. make entrypoint.sh fit with the deployment, then let aspects of development setup come secondary.