sample and instructions for installation via `docker-compose.yml`

[makeProjectGreatAgain]

sample and instructions for installation via docker-compose.yml

• ./docker-example/README.md was added
• ./docker-example/docker-compose.yml was added
• ./docker-example/.env.sample was added
• minor refac of Dockerfile and docker-compose.yml
• docs improvements

[HugoFara]

Hi, thank you for your pull request!

I looked at the proposed changes, but I'm not sure about your target, detailing below:

• Documentation improvements look good, Docker was just a feature a few months ago but an increasing number of users prefer it, so I can cherry-pick this part.
• I still have to check changes like DB_HOSTNAME=db → DB_HOSTNAME=${DB_HOSTNAME}. Using variables from .env file made things difficult in the past, I'm not sure yet if I should revert to this design (I will do some manual checks). Was that change necessary for you?
• I'm not convinced by the /docker-example folder yet. It is redundant, and does not follow the project's files organization. .env.sample can go into the main folder and README.md into docs/, but the new docker-compose seems will be confusing for users...

For now, you can let things as it for this PR, I will run some experiments with it!

[makeProjectGreatAgain]

Using variables from .env file made things difficult in the past,

This shouldn't be a problem, but you decide. Feel free to revert or edit PR. I have marked "Allow edits by maintainers"

Was that change necessary for you?

No. it's not necessary. I'm just accustomed to do this way

I'm not convinced by the /docker-example folder yet. It is redundant

I understand your point of view. You can feel free to refactor it in any way you see fit. Then you can either squash+merge or cherry-pick the relevant commits.

but the new docker-compose seems will be confusing for users...

I believe, this 'docker-compose' is the only one, that most users should use. Current docker-compose.yml is for building from source, what isn't common scenario for users. If you use docker images like ghcr.io/hugofara/lwt, it would be better to have a sample of 'docker-compose.yml' file that uses your existing image. To avoid any confusion with second docker-compose.yml, we can provide a sample of this file just in plain text in the 'README.md' or 'Install.md' :

version: "3.7"
services:
  web:
    image: ghcr.io/hugofara/lwt:master
    container_name: lwt
    depends_on:
      - db
    links:
      - db
    ports:
      - "8010:80"
    restart: unless-stopped
  db:
    container_name: lwt_db
    environment:
        MYSQL_ALLOW_EMPTY_PASSWORD: "no"
        MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    hostname: ${DB_HOSTNAME}
    image: mariadb:10.7
    restart: unless-stopped
    # all user data will be placed in local folder ./lwt_db_data
    volumes:
        - ./lwt_db_data:/var/lib/mysql
# volumes:
#   lwt_db_data: {}

[HugoFara]

Hi! I thought a bit about your intention with this pull request, and the interest for the project, here are my conclusions:

1. Your work is undoubtedly interesting.
2. However it is redundant with how LWT works.

As you said, currently docker-compose.yml is designed to build from source, without using the online image. Anyone wanting to use the online image would have to:

1. Download the full project.
2. Use docker compose to re-download the containerized project.

For me the best option is to create a new project containing only what you included as a folder, to serve as a easy-to-use Docker container. I may try that in a few days, does it make sense for you?

[HugoFara]

Hi! I adapted your work and pushed it to another repository, everything is at lwt-docker-installer. As far as I've tested it, it works well, thanks for the idea!