chore: unified dockerfile

[bodinsamuel]

Note

This is a proposal, open to debate.

Context

Fixes NAN-596

We currently maintain 4 Dockerfiles, and need to build 7 in total. I feel like it's a lot to maintain. As we grow we will add more images and more folder in packages which can results in more stuff being build for nothing and errors.

I would love to reduce this maintenance to 3 images (staging, prod, enterprise) and down to 1 if possible. Right now we need many versions also because we pass dedicated env vars to the Webapp build which is something we could do differently (e.g: serving those via API calls)

Proposal

• Build one unified Docker image nangohq/nango

It's currently 148MB (compressed) hub.docker.com vs nangohq/nango is 145MB. So the difference is already minimal enough that it doesn't really matter.

NB: the image is private rn

NB: I disabled build for entreprise for the moment. I feel like it would be a waste of time and if we manage to get rid of the Env Vars situation, the single image could serve this scenario.

Migration

If we agree the migration path is not urgent. We just need to take the time to do it when we want.
E.g for jobs:

• changing the image to nangohq/jobs:production to nangohq/nango:prod-<hash>
• adding a Docker Command, e.g: node packages/jobs/dist/app.js
• When we deploy, instead of triggering a new deploy on the same tag, we can trigger a deploy with the new image url

NB: this should also solve our docker caching issue

Should we keep the other images?

In the long-term I feel like it's not really useful, I think what other projects are doing is perfect with only 2-3 images:

• project/image_community
• project/image_entreprise
• project/image_private (for us)

[linear]

NAN-596 Unified docker images

[bodinsamuel]

Talked with @bastienbeurier we agreed on this solution, as long as we communicate and document the change.
We will keep building all others images until the migration is done on our side then deprecate their usage officially.

[bodinsamuel]

Can I have a review on this @khaliqgant @TBonnin? thanks ☺️

[khaliqgant]

Thanks Samuel. I think this makes sense, but the work here should be captured in a project within our ticketing system. I say that to make sure we encompass the impacted pieces of this change as a checklist of sorts.

• migration path
• how our customers affected (those who are self hosting and those enterprise)
• helm charts needed change: https://github.com/NangoHQ/nango-helm-charts

[bodinsamuel]

Good point I created a Linear project https://linear.app/nango/project/unified-dockerfile-1a4273be8741

[TBonnin]

do we currently use port 80. That would require an infra change if yes

[bodinsamuel]

locally we use 300x
on render we pass port in an env var, e.g:NANGO_JOBS_PORT
I don't think it will be much more complicated than changing the env var but my test on staging will tell us