search

docksal / docksal

Unified, Docker 🐳 powered web development environments for macOS, Windows, and Linux
https://docksal.io
MIT License
687 stars 179 forks source link

Docksal for Production #844

Open amjad-wp opened 5 years ago

amjad-wp commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

lmakarov commented 5 years ago

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:

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

achekulaev commented 5 years ago

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

lmakarov commented 5 years ago

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:

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

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 commented 5 years ago

@lmakarov why rudimentary fin instead of a real one?

lmakarov commented 5 years ago

@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 commented 5 years ago

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

lpeabody commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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?

dstorozhuk commented 2 years ago

Followed this instruction, and was able to run a few sites on a remote server. https://blog.docksal.io/installing-docksal-on-a-remote-server-digital-ocean-scaleway-etc-ed0c230ddb82 But, have a problem with self-signed certificate, it is still visible for a domain, as well as a certificate that I generated with certbot. And this makes the domain untrusted from mobile browsers. How to remove the self-signed certificate and use only these certificates that are placed in ~/.docksal/certs?

lmakarov commented 2 years ago

@dstorozhuk vhost proxy will pick up a cert from ~/.docksal/certs if there is one matching a particular domain.

The following may help setting the default domain/cert (instead of the self-signed one):

fin config set --global DOCKSAL_VHOST_PROXY_DEFAULT_CERT="your.default.domain.com"
fin system reset