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
4 changed files with 33 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.dockerignore
View File

@ -1,2 +1,5 @@
debian
node_modules
node_modules
.quasar
ldragan commented 2025-02-23 18:59:42 +00:00
Outdated
Review
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...?
build
.vscode

12
Dockerfile-front Normal file
View File

@ -0,0 +1,12 @@
FROM node:20-bookworm
ldragan commented 2025-02-23 18:48:56 +00:00
Outdated
Review
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.
RUN npm install -g pnpm@8
WORKDIR /hedera
COPY package.json pnpm-lock.yaml ./
RUN pnpm install
COPY . .
ldragan commented 2025-02-23 18:54:33 +00:00
Outdated
Review
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.
CMD [ "npm", "run", "front" ]

15
back/Dockerfile Normal file
View File

@ -0,0 +1,15 @@
FROM php:8.2-cli
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
Outdated
Review
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>`?
RUN docker-php-ext-install mysqli
ldragan commented 2025-02-23 19:00:55 +00:00
Outdated
Review
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.
WORKDIR /usr/src/hedera-web
COPY . .
WORKDIR /usr/src/hedera-web/back
CMD [ "php", "-S", "0.0.0.0:3002", "-t", ".", "index.php" ]

4
quasar.config.js
View File

@ -101,9 +101,9 @@ module.exports = configure(function (ctx) {
headers: { 'Access-Control-Allow-Origin': '*' },
// stats: { chunks: false },
proxy: {
'/api': 'http://localhost:3000',
'/api': 'http://salix-back:3000',
ldragan commented 2025-02-23 18:47:09 +00:00
Outdated
Review
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
Outdated
Review
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.
'/': {
target: 'http://localhost:3002',
target: 'http://hedera-back:3002',
bypass: req => (req.path !== '/' ? req.path : null)
}
}