My ideal scenarios: For developers: dependencies s...
# docker
c
My ideal scenarios: For developers: dependencies should be preinstalled, allowing for instant boot with optional filesystem mounting. For users in production: container should boot nearly instantly, and container should be immutable, with controlled runtime configuration via environmental variables/secrets
l
Currently, the proposed configuration may hit these targets, except for the first boot. The first boot will likely need to fetch the latest one-depth commit ID from the upstream git repository, and I question if it would be possible to adhere to the license requirements otherwise. I am happy to write it, so it's included; however, I didn't want to muddle with how the app is done or have to reverse engineer the code as a non-JS DSO; it didn't seem within the scope of my weekend drive-by.
A lot of the benefits from packaging up a container in the first place come from the security compartmentation and shipping the static environment. In this scenario its a very lean container by design, docker best practices recommend a target of less than 11 container layers. I believe this is technically 6. The instructions are also relatively simple and could potentially be easily ported to an Alpine base for a much smaller deployed footprint.
So long as Cal.com tend to pin their dependency versions if we only ship publishable container images based on upstream commit ID SHA hashes, the most significant time consumer would be the initial build step which only runs once. This methodology should also be relatively CI/CD compatible to allow end users and developers to maintain their local forks if they have custom code to add to the base. It also provides for variable string injection at container boot time to make CI/CD integration much smoother. The only thing I don't know how to add is a primary admin user without having to use Prisma Studio's UI, which seems like a clunky but maybe necessary option.
z
We recently added a wizard to add your first admin user if none is detected BTW
So prisma studio isn’t needed anymore for this
c
👍 👍 that's great news!
z
In theory you can spin up a new docker container and on first load it will ask you to create your first admin user. We're also looking into adding a UI to enable App store apps as well
l
Oh excellent! @zomars do you think that one could establish the
$ADMIN_USER
and
$ADMIN_PASS
and have that wizard detect that on boot?
z
We can use a custom seeder.ts for that
l
Can that be documented in the PR review as a TODO item? It would be awesome to make it completely headlessly deployable.
This way, you have the option never to expose an unconfigured instance to the world wide web.
z
Yes that makes sense
Tagging @leog as he built the wizard to hear his input
l
The other side is if the wizard can try running on the first boot, it fully prepares the codebase for CI/CD automation.
c
this is a wizard on the UI side though right? or is it a server-side seed script?
if it's on the UI side, then that takes it even further into the positive for me and a seed option can optional/icing-on-the-cake
l
hi there! yes, there is a client-side wizard to create the first admin user in the database
it is expected to be expanded with several other things to setup the instance, like app credentials, maybe branding
l
If the wizard can detect if the
seeder.ts
file and validate its entries then it saves me some sweat.