Containerize Kukkee

[anandbaburajan]

Containerize Kukkee

[jadlers]

Since I spent a little bit of time containerizing the application I thought I'd share the Dockerfile I created here. I know there are further steps required to build and publish the image on Docker Hub but it's a start!

FROM node:16-alpine
EXPOSE 3000

WORKDIR /app
COPY package.json package-lock.json /app/
RUN npm install

# Use a .dockerignore to skip copying node_modules
COPY . /app/
RUN npm run build

CMD npm run start

I also pair it with a .dockerignore file for anyone building it locally so that their local node_modules and .env files aren't included in the built image.

node_modules/
.env*

[anandbaburajan]

Thank you @jadlers! I'm quite new to Docker-izing applications so this is quite helpful. We'll have an image on Docker Hub soon!

[anandbaburajan]

Also, looking forward to hearing any feedback on how we can improve Kukkee! : )

[Leopere]

When it comes to containers some of the main tenets of containerization are; as ephemeral as possible, containing no state, easily replaceable, and finally one process per container.

As ephemeral as possible: meaning containers themselves should contain no state and be configured on boot through means of docker secrets for credentials and environment variables for configuration settings.

Containing no state: an expansion on ephemerality effectively you should keep all of the persistent application data, user data, uploaded media, databases, etc... within a volume outside of the container be it in a bind mount on the host filesystem or in a docker volume.

Easily replaceable: make it so that the app checks to see if its configured on boot and if it has all of its data and configurations do nothing but boot the application normally.

One process per container: One of the main benefits of containers is application isolation meaning that every application running in containers should be granted the least possible access to additional software and system features. This means that most container based applications are communicating with one another either using sockets or network interfaces.

A really great way to ensure that you're producing a useful Docker container is that you can supply the end users with a docker-compose.yml file which deploys a relatively unopinionated "kick the tires" deployment of your app so they can easily copy the compose file to their local and get a runnable instance locally for them to decide how to handle the future of their self hosted appliance.

You can add a .gitignore for the pattern docker-compose.override.yml directly into the app's git repository so that if people want to add their own features on top of your configuration they can without having to fork your repo.

Also you can add a .dockerignore (similar to .gitignore but for docker's container build process) for ignoring uncompiled source code so that doesn't get scanned on container build every single time you build a container.

If you follow most of these it should give you a healthy baseline for understanding how to publish a really great dockerized app.