That brings us right to the core of the problem! You’d be better off defining a baseline—and leaving the rest—for those who want to do things differently or simply can’t—as some sort of flimsy, nebulous add-on. That is precisely what signals reliability! Take Apache Guacamole, for example.
The key message should be this: “Our development takes place within environment XYZ. Follow our solid documentation, or go ahead and tinker with various container-based ‘workarounds’—just be aware that we won’t be responsible for them.”
I just migrated 11 → 12 → 13 and I am happy with this docker strategy.
Overall I am thankful to have found Seafile CE when Dropbox dropped support for many Linux file systems in 2018. It’s the only self-hosted option that is equally fast with large file sets.
Since I am a developer myself, I know it’s not always easy to learn new things, because there are new things all the time. But docker is simply a good choice. It is an industry standard. It barely has any overhead on Linux. It is so much easier to update, I’m glad I took the time. Went 11 → 12 → 13 just now. If this makes it easier to maintain the Community Edition, please - in my opinion, go right ahead.
Obviously I am in no way affiliated with Seafile. I was searching the forums to look for caveats to look out for during the upgrades, and saw the many complaints over multiple topics. Can’t I encourage you to look at the bright side? Do you know how much value there is in Seafile? All we have to do is make a docker setup and we can continue to use it for free.
Some of the complaints are from sys admins. How is it difficult to make a deployment script? Visualization and compartmentalization are the norm there days and it’s absolutely beautiful. Even hobbyists start to convert their Intel NUC devices to Proxmox boxes. You can create a new LXC with Debian/docker using Community-Scripts.org and you can even pool your resources and publish your own script to automate installing Seafile on that site so no one ever has to be frustrated again.
If you want to recreate on bare metal, you can see their own build script for Ubuntu basically in their latest Dockerfile here.
The two best discoveries I made after Seafile were Proxmox and Docker. Understanding them takes a time investment, but implementing them gave me much power in a power user sense. I’m now running dozens of LXC’s and even a few VM’s at home, and I use docker at work.
That’s all.
In my view, reliable software always rests upon a reliable foundational layer—entirely free of unnecessary intermediate steps. In the case of Seafile, that means Debian → Seafile.
It certainly does not mean Debian → Ubuntu → Docker → Seafile.
Attempting to look up installation instructions within a Docker container strikes me as somewhat comical.
With Proxmox—which you mentioned—the process works exactly like this, for instance.
This allows you to avoid the usual headaches associated with Seafile.
Hi all,
Just wanted to add my 2 cents here – I’ve been pretty reluctant to Docker, I thought it would be yet another layer that pretty frankly I could have done without especially for my SeaFile stack.
Although after having addressed my issues with it, I now see the Docker implementation as pretty solid, upgrades are really a hell of a lot easier, I find the whole configuration to be easier and straight forward compared to my former bare metal setup’s – over all I’m actually really happy with it now.
Though it is sure that there is a learning curve to be taken to embrace Docker based workflows.
In regards to migration from bare metal to Docker based, I first setup a new system/VM (full VM) using Docker, smashed it, bended it until I’d be happy with it – Then I reset’it up cleanly and migrated my datas over at once and shut down the older bare metal box once happy.
The only thing that I did drop from the proposed .yml package was the caddy reverse proxy in favor of a personally controlled nginx reverse proxy at the host(VM) layer with SeaFile running into self created Docker networks.
Hope this helps.
m
Docker support for nftables is still experimental. I’m not going to downgrade my servers with obsolete IP tables technology just to please one application instance. So, the devs, please, think twice (or more!) before jumping on the Docker-is-easier-for-everybody bandwagon: Docker is not a “standard”, it’s just a virtualization technology and surely not the best one, especially if all you need/have is a single VM instance. System administration is a profession: forcing sysadmins to bend their practice towards opaque (no directly accessible logs, minimal shell access often lacking useful command, no easy way of using UNIX sockets →that’s masochism!) Cloud-oriented solutions is an insult to the profession.
I just upgraded to CE v12 from v11, still bare-metal + Python virtual env and spent hours jumping across dozens of poorly written documentation pages, debugging and fixing my configuration. If it were Docker-based, that would have cost possibly 2x the time because of the obvious containers shell/files access limitations.
We need a thoroughly documented bare-metal + python venv installation process, because that’s what even the devs need when preparing a container-based installation.
For the time being, I’ll stay with a bare-metal v12 version until the “management” provides professionally written documentation. That’s an indispensable commitment for any serious enterprise and failing to do so will only prove once more that their products are not mature for professional usage or inclusion in any GNU/Linux distribution – please, find me one that provides official or community-curated Seafile packages. Just claiming that you offer a Pro version with premium (→+$) features doesn’t make Seafile a professional solution, sorry!
Have you considered podman? I had issues with docker as well, but after some experiments, I run now everything with podman (over 20 apps) and I am very happy about the clear separation of all apps.
1 Like
Ok it’s time. I’ll invest time into maintaining a well-made deb package - similar on how I did with vaultwarden and immich. I can’t stand docker. But it will be similar to the guidelines of those packages: trying to use system libs as much as possible and heavy sandboxing. Any help and input appreciated.
Can’t post links (yet?), look me up on github: repo seafile-deb