Help Dockerizing Lute - Githubissues

jzohrab commented 1 year ago

Hello all, if you're reading this, perhaps you have Docker experience and can help Dockerize Lute.

I've had a few people ask about having Lute Dockerized. It's been a loooong time since I've hacked on Docker, and I don't have the time or energy to spend fiddling with it. Perhaps someone is looking for a Docker project to try out, and would be willing to contribute.

Below is some info, LMK if you need more. This is a free project, I'm not looking to make money from it, and so I can't pay anyone. Hopefully this doesn't make you feel you're being taken advantage of ... (as a dev, I used to always feel that certain types of ppl were leeching off me) ... my limited dev time is better spent working on Lute itself.

Cheers and best wishes!

Jeff

Specs for Lute:

needs Apache (due to using Apache rewrites for URLs)
PHP 8.1 (and maybe later)
MySQL 8.0.31

More notes:

Lute users install and run Lute on their own machines. I'm not running a business, I just provide this free tool for language learners to use. So, this docker installation is for people to run on their own machines ... and perhaps it would be nice to have a Docker development environment as well. Your input appreciated. Users would be expected to have the necessary bits for Docker on their machines (Docker desktop or similar, docker compose, etc)
The project uses Symfony, a PHP framework, and php composer to pull in all of the packages. I am not sure if the code and framework should be built directly into the container, or if they should be mounted from an external directory ... your input appreciated.
The database migrations are managed automagically by the project -- Lute is given root access to the MySQL so that it can create tables, etc.
The project needs a single configuration file to describe the database connection params. Maybe these can be passed in as env params to the container -- or perhaps just the file is somehow passed in?
The project also stores some downloaded images in a /public/usermedia directory, so those would need to be ... mounted? Along with the db?
Users should be able to update their Lute by running the latest container (at which point the db migrations are automatically applied), or perhaps replacing the mounted code directory with newer code (and then somehow killing the cache in the container ... might get annoying)
The project build is single-click. CI is running locally and on GitHub.

16amattice commented 1 year ago

What is the default environment that SQL is expecting here?

environment:
  MYSQL_DATABASE: lute
  MYSQL_USER: lute
  MYSQL_PASSWORD: password
  MYSQL_ROOT_PASSWORD: password

jzohrab commented 1 year ago

Hi @16amattice , I figure that the db container would be a full installation of MySQL with the default information, which in some cases can be supplied during installation. https://hub.docker.com/_/mysql has some notes.

Perhaps all of this stuff could be passed to docker compose as a config file. Not sure! Perhaps every user should just be using a default config w/ default environment, so that it can be installed and run with no extra configuration -- would also make the deployment more standard, so that users don't accidentally mess up their config.

All open for discussion, of course. This is meant to simplify things for users to install. :-) Does that make sense? Cheers, jz

AdamHebby commented 1 year ago

Hello! Didn't see this discussion before I started working on it. Feel free to add to my PR, not got it fully working just yet, the tests can't connect to the test DB, think it needs some env changes

jzohrab commented 1 year ago

Hi @AdamHebby, thanks for the PR! I'll check it out -- have to get my Docker working first :-) Re the tests, it could be due to how Symfony manages the environments. When it's connecting to the regular DB, it uses .env, or is overridden with .env.local, but when running tests, it connects to .env.test or .env.test.local (ref https://symfony.com/doc/current/testing.html#customizing-environment-variables). Lute then requires the test database name to start with test_, because the tests are destructive and I'm paranoid.

fyi, my .env.test.local looks like this:

$ cat .env.test.local
DB_DATABASE=test_lute
DB_HOSTNAME=localhost
DB_USER=root
DB_PASSWORD=root

DATABASE_URL=mysql://${DB_USER}:${DB_PASSWORD}@${DB_HOSTNAME}/${DB_DATABASE}?serverVersion=8&charset=utf8

AdamHebby commented 1 year ago

Hi @jzohrab No worries! Yeah, it's mostly due to me assuming prod only and docker-compose only using .env, might either need a second docker-compose-test or something to only use the test env vars and run the app-init script with an argument to run the DB migrations on the test DB. Just needs a bit of thought around it is all.

jzohrab commented 1 year ago

Right, compose-test might make sense because then it's very explicit; or perhaps docker-compose-dev b/c really it's best to do dev in a specific environment. Whatever, as long as it's obvious for devs ... but then, maybe there would be a completely different setup for them (e.g. mounting the code dir as a volume or something), vs for end users (maybe everything just builds into the images?). I don't know what makes the most sense here. :-)

Lute manages the database migrations automatically ... every time the app connects to the db, it checks the db migrations to see if anything needs to be run. Yep, it's very wasteful :-) but it's just a single disk check for files against the db, so I didn't mind, and I don't notice it while running.

16amattice commented 1 year ago

I'll have to look at this tomorrow as well...I got a base setup that I believe is almost ready to run...just some things I have to tweak. I'll look at the PR tomorrow as well in case we are doing double work here lol

jzohrab commented 1 year ago

Super, thank you @16amattice .

16amattice commented 1 year ago

Not a problem! Looked a bit at the draft PR..and I added the composer install directly to the build. I made some other changes and am at the point of setting up the environment stuff. Just trying to stick with the portability aspect. I'll finish up tomorrow and throw a PR in.

99MengXin commented 1 year ago

Since @jzohrab release Lute v2-really-alpha, dockerise lute become very simple. Make and put these two files in lute dir, and run docker compose up -d.

Dockerfile

FROM php:8.2

# Install mecab for Japanese support
RUN apt-get update -y
RUN apt-get install -y mecab mecab-ipadic-utf8

# Clear cache
RUN apt-get clean && rm -rf /var/lib/apt/lists/*

WORKDIR /lute/public

CMD ["php", "-S", "0.0.0.0:8000"]

docker-compose.yml

version: "3.9"

services:
  lute:
    build:
      context: ./
      dockerfile: Dockerfile
    container_name: lute_2
    restart: always
    ports:
      - 8000:8000
    volumes:
      - .:/lute
    working_dir: /lute/public
    command: ["php", "-S", "0.0.0.0:8000"]

jzohrab commented 1 year ago

A great start, thank you @99MengXin ! I'm going to mess around with this a bit more before putting the dockerfile and compose into the repo. I'm going to see what I can do for the following:

prebuilt images pushed to docker hub, with the full app code in the image
storing the db and the images in mounted volume

jzohrab commented 1 year ago

Closing! The v2 beta has a working Docker image that runs well on a Mac. I'm going to assume that it will work on other systems as well ... and if it doesn't, then that's a separate dev ticket. Thanks to @16amattice , @AdamHebby , and @99MengXin for your notes, they all helped get this started. Cheers! jz

16amattice commented 1 year ago

Closing! The v2 beta has a working Docker image that runs well on a Mac. I'm going to assume that it will work on other systems as well ... and if it doesn't, then that's a separate dev ticket. Thanks to @16amattice , @AdamHebby , and @99MengXin for your notes, they all helped get this started. Cheers! jz

Always happy to help and good luck!

jzohrab / lute

Help Dockerizing Lute #8

Specs for Lute:

More notes: