gggrant commented 2 years ago

Some loose thoughts as I think on this:

inspiration of style will be https://github.com/compdemocracy/polis/blob/dev/docker-compose.yml
we want to do e2e testing. this would be simpler with a more "conventional" docker setup, that we could run in GitHub Actions environment
docker conventions of note
- one process per container (php, apache, etc)
- one dockerfile per section? (admin/talent/common)
- potentially multistage build for static builds, ie single dockerfile (for react build)
stretch goals (prob not in this PR)
- deploy container image artifacts to github container repo
- this would allow the containers to be built once, and then pulled into other jobs (no rebuild) for parallelized testing or other stuff
- demo: https://github.com/g0v-network/polis/blob/dev/.github/workflows/release-docker-images.yml
  - https://github.com/orgs/g0v-network/packages?repo_name=polis
great feature on smaller docker images: https://symflower.com/en/company/blog/2022/complete-guide-on-shrinking-container-images/

Prior Art

(Potentially useful when this is revived)

To Do

[x] https://github.com/GCTC-NTGC/gc-digital-talent/issues/2324
- [x] read peter's docker manifesto
- [x] @petertgiles 🙃
- [x] @patcon
- [x] @brindasasi
- [x] @JamesHuf
- [x] @gggrant
- [x] @RVany
- [ ] others? [add yourself]
- [x] schedule time -- @petertgiles [FRI MAR 25 @ 2-3pm]
- [x] invite all interesteds from thread -- @petertgiles
- [x] do the call! -- all
[x] optional: summarize goals as decided?
[ ] optional: split out tasks/tickets/accept-criteria (nearterm, longterm, etc)
[ ] https://github.com/GCTC-NTGC/gc-digital-talent/issues/2327

gggrant commented 2 years ago

@patcon to add description.

petertgiles commented 2 years ago

Result of planning session 2022-03-25:

Docker Manifesto

Goals

An easy way for new hires/contributors to get a working state
A reliable way for existing developers to reset their working state ~3. A reliable way for owners to deploy updates to production servers~ (not necessarily a problem with docker, deployment right now has nothing to do with docker)
A useful platform for automation

Priority Requirements

Must work on Windows, Mac, Linux
Must work on Github Actions

Secondary Requirements

Should conform to Docker best-practices
Should require few or no other dependencies
Good integration with VS Code

Nice-to-haves

Support constrained environments like TBS Azure VMs, Codespaces, GitPod
VS Code DevContainers
Easy way for Windows developers to use WSL2
One-click (or few-clicks) to check out and set up a branch for review.
Support for debugging PHP and Typescript
No build-time vertical setting changes - need single deployment artifact, but not a blocker since we can build multiple artifacts

Questions About Approach

One container per project? - yes, seems good
- Does frontend get one container for one per-subproject? - one for all of frontend is probably fine (maybe admin on its own?)
- Do we need two docker files per project? One with dev dependencies for development and one without for deployment to production. - containers are just for dev, could use flags/options to control
Docker Compose is only used for development, right? Production deployment should not use the compose file? - not using docker in production, could be interesting though
We should try to get rid of file mounts for node_modules, vendor, and storage to help speed up runtime and cache between branches and use volumes? - need to have a good experience figured out to enable this - task runner? - but would improve performance
- How do we avoid caching issues with volumes when switching branches? - should be pretty quick
Project containers should fully bootstrap themselves up on build - will probably be some stuff that can't be done this way, like auth - there should be a stage 2 including seeders, auth, etc
- How do we avoid layer caching issues when building a new container?
- How do we get auth secrets over to the api project on setup?
- Can we get ride of the infrastructure folder and have each project set up their own container independently?
How to solve the never-ending .env file issues? Validation on setup? - Try to minimize Docker's use of .env files, have docker copy in .env files, try to reduce number of .env variables inside files, check out node convict
Do we use containers with root user or rootless containers? - just use root, should be solvable
- Filesystem binds in Windows will come in owned by root but not on Mac or Linux.
- Can we get node to run as root properly?
Can we get rid of the maintenance container? - yes probably, use devconatiner, makefiles, etc to help dev experience
- Would we shell into the container of each project to run things like php artisan or npm run watch?
- If we have node_modules etc bound to internal volumes is there even anything we could do outside each container?
- What role would a vs code devcontainer have?
What role does the php container have if each project has its own container? - get rid of infrastucture folder and have a separate frontend routing folder, apache routing
- Do we need to have a infrastructure folder then?
- How do we handle top-level htaccess/routing stuff without it?
Can we get rid of the maintenance scripts and just teardown/rebuild a container every time?
How can we support people not using VS Code - makefiles inside containers?

patcon commented 2 years ago

@petertgiles in backlog refinement, others wanted to know if we could easily handle https://github.com/GCTC-NTGC/gc-digital-talent/issues/2327 -- seemed easy enough, so added it to todos above :)

patcon commented 2 years ago

minimal base image for ubuntu that may be helpful in future (but likely not): https://github.com/phusion/baseimage-docker (maybe helpful HN context)

patcon commented 2 years ago

hyperlink gifts from @petertgiles --