yarn is now used for the joplin project

[tessus]

You might want to check the new file https://github.com/laurent22/joplin/blob/dev/Dockerfile.server

[hi-ko]

Hi @tessus, thanks for your notification.

I will try to adapt and create a ticket in the joplin project. Build process to create the joplin artefacts and the dockerfile should be separated, otherwise other deployment variants like debian package installs will always potentially inhabitable if not reviewed manually on any change in the dockerfile ...

[bernd-wechner]

Thanks for spotting that.

[bernd-wechner]

Looking at that file though, it looks so close to bash that a translator is easy to imagine. I wonder if one has already been written? What's the format of that file? Is that a Docker composer file? Or? This is my steep learning curve.

[tessus]

This is a docker file.

A compose file is this one: https://github.com/laurent22/joplin/blob/dev/docker-compose.server.yml

But you do not need the compose file, because you are not running containers. You just need the info how the server is actually built. And you can get that info from the docker file for the server.

[bernd-wechner]

Thanks. Think this clarified it a bit for me:

Dockerfile -> Docker Image -> Compose File -> Running Containers

which I found here: https://linuxhandbook.com/docker-file-vs-docker-compose/

Have we got a 4th player now, interested in dockerless Joplin server install?

[tessus]

Many people are interested in installing Joplin Server without Docker. There's a topic on the forum and a guide I think.

When it comes to distributing SW, it's often easier with Docker and also docker deployments are a standard these days. If you're interested in learning Docker, a good resource is The Docker Book. It's like $10, but even has advanced topics in there.

[bernd-wechner]

There is, and this is the guide ;-). It's how we land here ... thanks to Hi-ko's post on the thread.

[hi-ko]

@tessus I'm pretty aware of docker but there are good reasons to choose other runtimes. e.g. docker running in production requires something like K8s to adapt features like a watchdog which you have for free by systemd. That's the reason why I run our family cooking and shoppinglist joplin in a linux conainer (lxd). Additionally most end users running joplin don't know how to handle storage, backup / recovery correctly not to loose the content with the next update.

So all I request for is to separate the generic joplin server build from the docker image build so we can catch up the first one without headaches instead of parsing and translating the dockerfile on any update.

[rokdd]

Well I choose this scripts because I do not want to use docker on my Raspberry Pi and by the way I read / think Docker is something waste of energy / resources just to make something more easy.

[hi-ko]

Docker is great from a developer perspective: you don't need to care about the installation and infrastructure, you just fire up a docker compose and you can just use it from your dev environment. This changes if you want to run the same solution in production. You need a totally different knowledge and setup. Running a server with docker compose is like running a server with VMPlayer from your desktop. Additionally, doing a simple change will allways require to compile a custom image or configure an overlay. I have seen users several times loosing all their data because they don't understand the concepts of docker. So always make sure you understand what you're doing ...

For running a solution on a server I prefer Linux Container (LXD). It's closer to a VM simulating a real OS but uses less resources than a docker setup. You can also just log into the conainer and change config, install stuff like in a VM but you also benefit from the LXD features like clustering, images, snapshots.

[rokdd]

I found this repo to convert the docker file to shell commands: https://github.com/devgateway/dkr2sh

Can we open a wiki or something to collect?

[tessus]

@hi-ko

I'm pretty aware of docker but there are good reasons to choose other runtimes.

I was replying to bernd. ;-) And, yes. There are many good reasons to use other runtimes. e.g. I dislike running databases in containers. Maybe because I was in DB2 development and a performance engineer, or maybe because persistent storage can be a mess with container orchestration. Running containers on a single server without orchestration is much simpler and it is also easier to handle persistent storage. Still, I am not a fan of running any backend system in containers. However, there are always exceptions to the rule.

I'm pretty aware of docker but there are good reasons to choose other runtimes. e.g. docker running in production requires something like K8s to adapt features like a watchdog which you have for free by systemd.

This really depends. If you don't use orchestration, you can still have restart container options and whatnot. Running a Nomad or k8s cluster for Joplin might be an overkill anyway. However, thereotically you could write a simple Nomad job to run multiple Joplin server instances (behind a traefik or haproxy LB) which all use the same database (containerized or not). But as I said... mega overkill.

But for the not so technical inclined person, a container deployment is often a lot easier to manage. Also the update of the software is easier. As you can see there's a compose file that uses a bind mount. If the documentation is lacking, we can certainly work on that. Have you ever tried to run Discourse not in a container? A friendly piece of advice: Don't.

Also, for support purposes we can be sure that the same code is used when people are using the same image. When you install stuff manually, the dependencies could all differ and you might even use a different version of Postgres.

[bernd-wechner]

I found this repo to convert the docker file to shell commands: https://github.com/devgateway/dkr2sh

Can we open a wiki or something to collect?

I had found this one:

https://github.com/thatkevin/dockerfile-to-shell-script

But it looks like devgateway's is better. Eitehr way we should work on automating the build to use one of those I suspect in a three step process:

1. configure build: create build.sh using one of those converters
2. Inspect result and tweak as needed
3. Run build.sh

[rokdd]

Well I guess it needs like a structure what it needs to automatize the process fully and embed into a Debian package? For example, does the installer download and convert the script or do we need this beforehand to update dependencies,.. like compile the package?

[bernd-wechner]

I've just tried sharing a notebook with 2.6.14 and no luck. The got the email, installed joplin, synch with the server, but don't see the notebook I shared. Rather than try and diagnose that it's a better plan to upgrade to the latest server (which may have fixed that). So what time I do make I'd invest into that.

[rokdd]

Some links I found for creating the .deb packages:

• https://coolaj86.com/articles/how-to-create-a-debian-installer.html / the redeb.sh is here
• https://github.com/heartsucker/node-deb