verdnatura/hedera-web
verdnatura
/
hedera-web
0
1
Fork 2
Code Issues Pull Requests 6 Releases Wiki Activity

WIP: dockerfiles for local development #116

Draft
ldragan wants to merge 1 commits from ldragan/hedera-web:taro/docker into beta
pull from: ldragan/hedera-web:taro/docker
merge into: verdnatura:beta
Conversation 0 Commits 1 Files Changed 4 +33 -3
ldragan commented 2025-02-23 18:35:21 +00:00
First-time contributor
Copy Link
No description provided.
ldragan added 10 commits 2025-02-23 18:35:21 +00:00
gitea/hedera-web/pipeline/pr-beta There was a failure building this commit Details
4f6b7b7632 chore: add docker files for local development for backend and frontend
ldragan added 2 commits 2025-02-23 18:36:23 +00:00
gitea/hedera-web/pipeline/pr-beta There was a failure building this commit Details
b967d2fee1 .
ldragan added 1 commit 2025-02-23 18:37:44 +00:00
gitea/hedera-web/pipeline/pr-beta There was a failure building this commit Details
d3cb226ccc .
ldragan added 1 commit 2025-02-23 18:38:33 +00:00
gitea/hedera-web/pipeline/pr-beta There was a failure building this commit Details
e6b8c1cac1 .
ldragan added 1 commit 2025-02-23 18:39:06 +00:00
gitea/hedera-web/pipeline/pr-beta This commit looks good Details
9b61b6af73 .
ldragan reviewed 2025-02-23 18:47:09 +00:00
quasar.config.js Outdated
@ -102,3 +102,3 @@
// stats: { chunks: false },
proxy: {
'/api': 'http://localhost:3000',
'/api': 'http://salix-back:3000',
ldragan commented 2025-02-23 18:47:09 +00:00
Author
First-time contributor
Copy Link

Estos cambios son necesarios para poder correr esto dentro de docker con un archivo docker-compose.yml que tengo en un repo propio, que aún no subí a ningún lado.

El archivo, de momento, es así:

services:
  mysql:
    image: mysql:5.6
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: root

  hedera-back:
    build:
      context: ../../hedera-web
      dockerfile: back/Dockerfile
    ports:
      - 3002:3002

  hedera-front:
    build:
      context: ../../hedera-web
      dockerfile: Dockerfile-front
    ports:
      - 8080:8080

  salix-back:
    build:
        context: ../../salix
        dockerfile: back/Dockerfile
    ports:
      - 3000:3000
    environment:
#      - VN_MYSQL_HOST=salix-db
#      - VN_MYSQL_HOST=mysql
      - VN_MYSQL_HOST=35.169.154.21
      - DEBUG=loopback:user

(35.169.154.21 es la IP de la máquina que tengo en AWS corriendo la DB)

Hay varias cosas para charlar aquí.

Por un lado, me gustaría que estas URLs sean parametrizables via env vars.
Por otro, sería sencillo tener una imagen de nginx corriendo en docker-compose que se encargue de esto, y, directamente, ni usar el development server proxy.

Creo que probaré hacer eso hoy. En ese caso creo que podríamos simplemente revertir estos cambios y ni si quiera tocar este archivo en absoluto — limitándonos a la introducción de un nginx.conf y una entrada en el docker-compose.yml. Sería algo similar a lo que, asumo, tienen en producción.

Estos cambios son necesarios para poder correr esto dentro de docker con un archivo docker-compose.yml que tengo en un repo propio, que aún no subí a ningún lado. El archivo, de momento, es así: ```yml services: mysql: image: mysql:5.6 ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root hedera-back: build: context: ../../hedera-web dockerfile: back/Dockerfile ports: - 3002:3002 hedera-front: build: context: ../../hedera-web dockerfile: Dockerfile-front ports: - 8080:8080 salix-back: build: context: ../../salix dockerfile: back/Dockerfile ports: - 3000:3000 environment: # - VN_MYSQL_HOST=salix-db # - VN_MYSQL_HOST=mysql - VN_MYSQL_HOST=35.169.154.21 - DEBUG=loopback:user ``` (`35.169.154.21` es la IP de la máquina que tengo en AWS corriendo la DB) Hay varias cosas para charlar aquí. Por un lado, me gustaría que estas URLs sean parametrizables via env vars. Por otro, sería sencillo tener una imagen de nginx corriendo en docker-compose que se encargue de esto, y, directamente, ni usar el development server proxy. Creo que probaré hacer eso hoy. En ese caso creo que podríamos simplemente revertir estos cambios y ni si quiera tocar este archivo en absoluto — limitándonos a la introducción de un nginx.conf y una entrada en el docker-compose.yml. Sería algo similar a lo que, asumo, tienen en producción.
ldragan commented 2025-02-25 16:31:58 +00:00
Author
First-time contributor
Copy Link

Update: efectivamente, con un nginx en el docker-compose.yml nos evitamos tocar el proxy del dev server. Voy a revertir estos cambios.

Update: efectivamente, con un nginx en el docker-compose.yml nos evitamos tocar el proxy del dev server. Voy a revertir estos cambios.
ldragan reviewed 2025-02-23 18:48:56 +00:00
Dockerfile-front Outdated
@ -0,0 +1,12 @@
FROM node:20-bookworm
ldragan commented 2025-02-23 18:48:56 +00:00
Author
First-time contributor
Copy Link

Probé varias cosas y eventualmente llegué a este setup como el más sencillo. Usar corepack o pnpm como un binario (con nodejs bundled) fue más complicado y problemático, y, considerando que pnpm está hecho en JavaScript en primer lugar, usar la imagen de docker de nodejs e instalar pnpm con npm me pareció lo menos error prone.

Funciona perfectamente en mi máquina.

Probé varias cosas y eventualmente llegué a este setup como el más sencillo. Usar `corepack` o `pnpm` como un binario (con nodejs bundled) fue más complicado y problemático, y, considerando que `pnpm` está hecho en JavaScript en primer lugar, usar la imagen de docker de nodejs e instalar `pnpm` con `npm` me pareció lo menos error prone. Funciona perfectamente en mi máquina.
ldragan reviewed 2025-02-23 18:54:33 +00:00
Dockerfile-front Outdated
@ -0,0 +7,4 @@
COPY package.json pnpm-lock.yaml ./
RUN pnpm install
COPY . .
ldragan commented 2025-02-23 18:54:33 +00:00
Author
First-time contributor
Copy Link

Normalmente, para local dev, haríamos un mount, compartiendo archivos con el host, pero

  • lo hice así para simplificarme el desarrollo inicial del dockerfile
  • en la práctica demostró ser tan muy rápido, así que, al final, no le dediqué tiempo a montar un volumen, compartiendo archivos con el host
  • en mi experiencia, montar un volumen, compartiendo archivos con el host, suele ser problemático y confuso, por un tema de ownership de los archivos.
  • creo que, independientemente de si queremos montar un volumen, es importante tener un dockerfile que haga COPY, ya que es más similar a prod, para probar los cambios localmente al menos una vez antes de abrir un PR, y para ayudarnos a debuggear cuando hay issues (para descartar temas que originan por montar un volumen)

Si quieren, puedo probar hacer un nuevo dockerfile, que monte un volumen, pero realmente me gustaría tener este con COPY, y, a lo sumo, tener 2 distintos, y no uno solo que haga mount y nunca copy.

En el caso del mount, también me gustaría que haga mount de src y no de ., haciendo copy del resto, para evitar la posibilidad de que node_modules y otros archivos no-versionados sean modificados accidentalmente por ambos el contenedor y el host.

Normalmente, para local dev, haríamos un mount, compartiendo archivos con el host, pero - lo hice así para simplificarme el desarrollo inicial del dockerfile - en la práctica demostró ser tan muy rápido, así que, al final, no le dediqué tiempo a montar un volumen, compartiendo archivos con el host - en mi experiencia, montar un volumen, compartiendo archivos con el host, suele ser problemático y confuso, por un tema de ownership de los archivos. - creo que, independientemente de si queremos montar un volumen, es importante tener un dockerfile que haga `COPY`, ya que es más similar a prod, para probar los cambios localmente al menos una vez antes de abrir un PR, y para ayudarnos a debuggear cuando hay issues (para descartar temas que originan por montar un volumen) Si quieren, puedo probar hacer un nuevo dockerfile, que monte un volumen, pero realmente me gustaría tener este con COPY, y, a lo sumo, tener 2 distintos, y no uno solo que haga mount y nunca copy. En el caso del mount, también me gustaría que haga mount de `src` y no de `.`, haciendo copy del resto, para evitar la posibilidad de que `node_modules` y otros archivos no-versionados sean modificados accidentalmente por ambos el contenedor y el host.
ldragan reviewed 2025-02-23 18:58:23 +00:00
back/Dockerfile Outdated
@ -0,0 +3,4 @@
RUN apt-get update && apt-get install -y --no-install-recommends git
WORKDIR /usr/src
RUN git clone https://gitea.verdnatura.es/verdnatura/php-vn-lib.git
ldragan commented 2025-02-23 18:58:23 +00:00
Author
First-time contributor
Copy Link

Cosas para mejorar del git clone:

  • --depth=1?
  • --single-branch?
  • git clone -b <commit id / tag / branch>?
  • ENV PHP_VN_LIB_VERSION=<commit-ish>?
Cosas para mejorar del `git clone`: - `--depth=1`? - `--single-branch`? - `git clone -b <commit id / tag / branch>`? - `ENV PHP_VN_LIB_VERSION=<commit-ish>`?
ldragan reviewed 2025-02-23 18:59:42 +00:00
.dockerignore Outdated
@ -1,2 +1,3 @@
node_modules
node_modules
.quasar
ldragan commented 2025-02-23 18:59:42 +00:00
Author
First-time contributor
Copy Link

Estos cambios afectan tanto al nuevo dockerfile que introduce este PR como el existente. Eso introduce cierto riesgo de afectar a prod. No sé si es deseable mantener estos cambios, o ver la forma de tener dos .dockerignores distintos...?

Estos cambios afectan tanto al nuevo dockerfile que introduce este PR como el existente. Eso introduce cierto riesgo de afectar a prod. No sé si es deseable mantener estos cambios, o ver la forma de tener dos `.dockerignore`s distintos...?
ldragan reviewed 2025-02-23 19:00:55 +00:00
back/Dockerfile Outdated
@ -0,0 +5,4 @@
WORKDIR /usr/src
RUN git clone https://gitea.verdnatura.es/verdnatura/php-vn-lib.git
RUN docker-php-ext-install mysqli
ldragan commented 2025-02-23 19:00:55 +00:00
Author
First-time contributor
Copy Link

Honestamente llegué a esto a prueba y error.

"works in my machine" lol

Considerando que el objetivo es ya no tener PHP en absoluto dentro de poco tiempo, "works in my machine" es good enough, IMO.

Honestamente llegué a esto a prueba y error. "works in my machine" lol Considerando que el objetivo es ya no tener PHP en absoluto dentro de poco tiempo, "works in my machine" es good enough, IMO.
ldragan force-pushed taro/docker from 9b61b6af73 to c55d4b93ee 2025-02-24 06:45:14 +00:00 Compare
ldragan requested review from jsegarra 2025-02-24 21:07:25 +00:00
ldragan requested review from juan 2025-02-24 21:09:37 +00:00
All checks were successful
gitea/hedera-web/pipeline/pr-beta This commit looks good
Required
Details
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
Reviewers
No reviewers
jsegarra
juan
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: verdnatura/hedera-web#116
No description provided.
Delete Branch "ldragan/hedera-web:taro/docker"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?