Docksal: Docksal for Production

[amjad-wp]

Hi All,

I know I am being a bit optimistic.
But I am kind of getting addicted to Docksal for all my projects.
Will there be any opportunity to run it in Production in future ?
With Kubernetes and stuff like that ?
Or is there any documentation regarding running Docksal containers and fin on Production environment ?

Regards,
Amjad

[achekulaev]

Well for what it's worth, you can always try this.
https://blog.docksal.io/installing-docksal-on-a-remote-server-digital-ocean-scaleway-etc-ed0c230ddb82

I know some people do Docksal on PROD, but I didn't really hear the feedback on how well was it doing there.

[mike-potter]

Honestly, you shouldn't need Docksal on production. On Production you are already on linux which natively supports docker. You don't need VMs and NFS/osxfs/unison mounts. "fin" is just a bash script that makes some of the docker stuff a bit easier, but you should be able to do docker natively.

If you need a docker-compose.yml file you can use part of the output from "fin config".

Kubernetes isn't really the same as docker (see Google for diffs). It's more complicated. So not sure Docksal will help you there.

We are using Kubernetes on Google cloud via GitLab for CI and don't need to use any Docksal stuff for that. We only use Docksal for local dev. For us, production environments are usually client dictated. Most aren't even set up to run containerized and still use vagrant/puppet or a hosting server like Acquia or Pantheon. So it really depends a lot on your specific case.

[amjad-wp]

@mike-potter Would it not be feasible if some command like fin export exports everything in something like docker-compose.yml and then when I deploy to server I can use some docker-compose commands ?

Just throwing out ideas there.

[shelane]

You can run fin config to get the entire compose output.

[lmakarov]

Internally (at FFW) we use Docksal for local dev as well as sandbox environments in CI. If interested in using Docksal in CI, take a look at:

• https://github.com/docksal/ci-agent
• https://github.com/docksal/sandbox-server
• https://2018.badcamp.org/session/sandbox-cicd-environments-everyone

As @mike-potter pointed out, production hosting is dictated by the client in the majority of cases, so pushing Docksal all the way to prod has not been the goal.

We are using Kubernetes on Google cloud via GitLab for CI and don't need to use any Docksal stuff for that.

@mike-potter anything you can share? I'm working on a setup for a client involving GitLab and (possibly) Kubernetes. It would be good to see some examples/case studies from others on this.

[mike-potter]

@lmakarov Still trying to work it out. Kubernetes (Helm, etc) is a whole new language I'm trying to learn ;) So far our projects using it have been very client specific, but hoping to have something more general in a few months. But probably won't have anything Docksal-specific in it.

One thing Docksal could do to help is add an option to "fin config" that only outputs the docker-compose.yml data. That would make it a lot easier to share configuration between Docksal locally and with a CI environment that is more "pure docker".

[lmakarov]

One thing Docksal could do to help is add an option to "fin config" that only outputs the docker-compose.yml data

@mike-potter This option already exists - fin docker-compose config (fin dc config).

[mike-potter]

Oh, thanks very much for that! Apparently I didn't even know about the fin docker-compose command. I need to spend more time digging through fin help !!

[amjad-wp]

@mike-potter same here. Everyday a new discovery in Docksal surprises me how powerful the tool is.

[achekulaev]

I will close this since there is no action items here, but feel free to add to the discussion.

[lmakarov]

I'm actually working on this (Docker based Drupal stack for production use) for a client right now.

I made the assumption that Docksal is not installed in the production environment and trying to figure out what this would look like. Also assuming a single host setup for now - no Swarm or K8S, just plain docker/docker-compose.

So far, it's a mix of:

• docker-compose.yml using Docksal images for the project stack
• Makefile with shortcuts to docker/docker-compose commands to start/stop/bash/etc. (basically, a rudimentary fin in under 100 lines of code)
• A bunch of .env files that get selectively loaded in the Makefile for different environments (e.g. stage vs prod)

There is also a separate stack definition (docker-compose.yml + Makefile) for system services:

• Traefik for ingress (replaces docksal/vhost-proxy). Trying it out for now. May switch back to docksal/vhost-proxy.
• A few extra treats like portainer and ctop that would simplify management and monitoring

One of the open questions is figuring out which images to use for the production stack. We can either maintain our own production grade library (which would be preferable from the continuity standpoint) or reuse someones (e.g. Wodby's).

cli service is the biggest question so far, since it's the richest and most complex service in the Docksal stack. We are, most likely, have to split it into docksal/php-fpm (PHP/PHP-FPM stuff only, no console tools) and docksal/cli (composer, drush and everything else), with the latter inheriting from the former one.

Thumb up if interested and I will post updates as I move along with this.

[achekulaev]

@lmakarov why rudimentary fin instead of a real one?

[lmakarov]

@achekulaev because this is a POC and I want to start fresh with it, see where it goes and then decide what to do with the results.

[lukasfischer]

Wondering if there is progress on this? If you could share any insights, I'm highly interested.

[lpeabody]

@lukasfischer Give @lmakarov a thumbs up in his approach post a few posts up from this one. @lmakarov is it worth keeping this open for you to post your results in? I'd be very interested in hearing about how you approached this, and what your results were. We have to do a VPS-based hosting project for a client and I'd love to just use what we already have with our Docksal stack, but tweaked for production.

[lmakarov]

Here's my POC setup: https://github.com/lmakarov/docksal-prod-poc

There are still a few rough parts and challenges to deal with, but it should be functioning.

[macmladen]

I will join here, to add some fuel 🙂

First of all, I really do like the ability to be able to pass just configuration and have Docksal projects on live server (not to mention the full flow, local, stage, live). While that may seem not optimal and it is actually very easy to deploy site regularly, It helps to be able to easily push them to server and to have them just work.

That being said, @lmakarov it may be a good idea anyway to separate tools from PHP-FPM as true docker philosophy and probably easier to maintain. This way, tools can be excluded on server (although they do not take too much anyway).

Now, there are many scenarios how to make the stack go live, one is to use vhost-proxy which would make it easier to deploy multiple stacks (or Traefik or anything else), other is to be self sufficient but then we have a problem with port/name resolving, and overall seamless integration.

I saw this post by @david-hernandez Setting up a server with Docksal where he made it into simple VPS.

I use Aegir solution based on BOA script where I also have some sites outside Aegir so I was thinking about having vhost_proxy work on some other port and then route that to main nginx server.

I'll post my findings but so far, I am just simply deploying them into Drupal 8 custom distro (in Aegir lingo).

[cybtachyon]

I'm also curious about the converse setup - using from-scratch production images with local Docksal dev, while maintaining the additional layers of Docksal features & settings support.

Use cases:

• Groups who already have production images that would like to use Docksal for local dev, migrating from plain docker-compose or more convoluted setups
• Groups who need a large amount of customization to their production images, and need their local dev images to match for a myriad of reasons
• Groups who cannot (for a number of reasons) use Alpine as a base
• DevOps teams who hate "it works on my local" syndrome...

There's not an easy "Step by Step" to rolling Docksal-compatible images from scratch that I could find, which would make this sort of thing easier. https://docs.docksal.io/stack/extend-images/ covers some of it, but to figure out the rest you need an in-depth knowledge of the Docksal stack and then spend time digging around through the dockerfiles for the alpine containers.

Anyone make progress here that would be interested in a remote lunch & learn sort of thing?