https://cal.com logo
Join Slack
Powered by
I see that there's a basic boot mode, but if the b...
# docker
c
I see that there's a basic boot mode, but if the bootstrap and a volume definition isn't already there, then that looks like it won't run on first boot
l
I added volume detection and complain functionality to allow the container to detect if it will have persistence between container starts. I could set it to fail if it doesn't see a volume mounted at 
$APP_PATH
to be more opinionated, it seemed more beneficial to allow end users to deploy and test without committing to anything.
c
volume mounts should be an option but not a requirement, and I should be able set read-only-filesystem flags
l
Currently, as per my design once you've deployed your code you can restart your container in 
basic_start
which happens automatically if 
[[ -f $APP_PATH/package.json ]]
is true. You would be fine to set the 
$APP_PATH
volume as Read Only, also technically this can be even managed with SEL rules via 
chmod
On first boot and during upgrades, you may be forced to switch the 
$APP_PATH
volume out of RO mode or perhaps even maybe boot a secondary copy of this container designed never to be public that would be in bootstrap mode only when the commit ID changes.
c
I need to be able to run from the outset without write access
l
Can you describe the reasoning? I'm not sure I haven't covered your concerns already.
c
I'm following kubernetes principles for immutable containers
(roleplaying a bit here as an enterprise admin)
l
I can potentially program in some logic to bake the git repository directly into the container itself.
The container itself is immutable I just don't know how to avoid breaking with the license clause that says no repackaging and distribution while also providing that.
So either we need written permission legally speaking from the Cal.com company officials themselves or I think the only way to comply with their chosen license is to do something like this.
c
the core challenge with the image in general has been the lack of support of runtime configurability without requiring a rebuild
sorry, a bit distracted in meetings right now, trying to articulate it
I think we're talking around the same motivation
l
The only thing that really gets in the way of it not being entirely a one mode, one step boot process is the build process. Which from what I understood was that build time dependency where you have to build the Dockerfile locally. Now I am making assumptions here based on just reading the code so forgive me if its entirely incorrect but it seemed like the build process needed to be done close to if not directly in the end users environment. Some of the Git Issues alluded to and confirmed this with mentions of 
<http://localhost:3000>
being in a lot of the code everywhere in deployed instances.
No problem! I'm just happy you're giving me such good feedback!
I added so much to this PR that its kind of hard to explain the fullest intent and reasoning behind all of my contribution in comments and the PR submission itself so this chat makes it super helpful.
c
I think the thing I'm fixated on in this scenario is that the new dockerfile doesn't have any building/packaging. The scripts, global prisma package, and some OS packages are the only thing that get baked into the image
(that's not to say that some of the bootstrapping can be called in the image build! re-bootstrapping can remain an optional run mode)
l
There is TLS between GitHub and the developer and a cryptographic chain of trust and delivery between the coder's keyboard and this container. Re-bootstrapping still only runs if it's not detected to have already been bootstrapped.
I'm still feeling like for the most part this container adheres to most of the concerns its just this one that seems somewhat unresolved. It can be added so that we package the git repository at whatever commit into the container but I can't pre-build it on your environment for you unless there may be some re-architecting on the app itself.
bootstrap_start
only runs when its not already bootstrapped you can bootstrap it yourself in your IDE probably or also somehow using the target deployable server.
However 
basic_start
can only run if it has files to run and either we have to break the license clauses about repackaging or have permission to do that.
I apologize if I'm sounding a bit terse. Just trying to communicate just the facts as I interpret them. I hope that's alright.
As for immutability, with the cryptographic chain of custody implied by git you know that the code being deployed is a byte-perfect replica of what you request. Then if you wish you can add it into the start script which is immutable and can't be edited by any special users (IF we wish to ad them) for reduced privilege execution.
You can add the code to that. However, ultimately the cryptographic signature is externalized to the git repository in this configuration and it adheres to the clause regarding repackaging.
I hope these perspective suggestions are useful/persuasive.
2 Views
Open in Slack
PreviousNext
Powered by