Page MenuHomekolab.org

Deployment configs
ClosedPublic

Authored by mollekopf on Oct 11 2022, 12:07 AM.

Details

Summary

A bin/configure script copies everything deployment specific in the right locations.

Notes

  • We copy because symlinks don't work in docker containers where we sometimes only mount src/
  • Artisan commands + config could be included, but aren't atm.
  • The theme can be included via config/theme
  • The provided config works for the docker-compose localhost setup, I have another config for a localhost development setup via 127.0.0.1 where kolab4 runs on the host.
  • Most migrations where relatively straightforward to separate between seed/and regular migration, only 2022_05_13_100000_permissions_and_room_subscriptions.php was a bit more involved because it changes the schema, migrates existing data over, and then drops the old data. This is now solved by first running a seed-migration that create the new seed entry (deployment specific), and then run the schema change that generically moves existing data over.

Diff Detail

Repository
rK kolab
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

mollekopf requested review of this revision.Oct 11 2022, 12:07 AM
mollekopf created this revision.
mollekopf updated this revision to Diff 11090.Oct 11 2022, 12:10 AM

Fixed production seeder

mollekopf updated this revision to Diff 11093.Oct 11 2022, 12:16 AM

Removed production seeder

mollekopf added a reviewer: Restricted Project.Oct 11 2022, 12:18 AM
mollekopf edited the summary of this revision. (Show Details)Oct 11 2022, 12:22 AM
mollekopf added a project: Restricted Project.
mollekopf edited the summary of this revision. (Show Details)Oct 11 2022, 12:26 AM
mollekopf updated this revision to Diff 11165.Oct 19 2022, 10:41 AM

Deployment configs as a filesystem overlay

The configure.sh script does what .s2i/bin/assemble does, in that it copies the overlay over the repository.
For the default setup we provide config.local, for a production environment we use one of our theme repositories (after resturcturing like we did for kolabnow).

This migration thing is a mess and will be problematic in the future. I however have no better idea. We'll have to be very careful in the future. And this makes managing Kolab4 installation (and updates), if you are not Apheleia IT, very difficult.

I have one point that would have to be verified. You created some new migration files. Won't they all be executed when we deploy this change? I'm afraid they will, because the system will not find them in the migrations table, even though they have an old timestamp in the filename.

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

This migration thing is a mess and will be problematic in the future. I however have no better idea. We'll have to be very careful in the future. And this makes managing Kolab4 installation (and updates), if you are not Apheleia IT, very difficult.

I don't disagree ;-)

I have one point that would have to be verified. You created some new migration files. Won't they all be executed when we deploy this change? I'm afraid they will, because the system will not find them in the migrations table, even though they have an old timestamp in the filename.

I think you are correct, we either need to keep the old names or make sure no harm is done by running the migration again.

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

This should actually be fine.

2022_05_13_090000_permissions_and_room_subscriptions is part of the "local" config, and as such will not be deployed to kolabnow.
The problematic part is here: https://bifrost.kolabsystems.com/D3235, I suppose there we should simply remove those migrations as they serve no purpose there.

Stripping all the secrets will require some additional setup-procedure to generate them, so I'm not going to do that in this patch. The situation has not actually gotten worse because I just concatenated src/env.example and ansible/env.local into ansible/env.

mollekopf updated this revision to Diff 11231.Fri, Nov 4, 3:42 PM

Cleaned up .env files & follow symbolic links in configure.sh

This revision was not accepted when it landed; it landed in state Needs Review.Wed, Nov 16, 4:27 PM
Closed by commit rKe5c1e3164a83: Deployment configs (authored by Christian Mollekopf <mollekopf@apheleia-it.ch>). · Explain Why
This revision was automatically updated to reflect the committed changes.