Pantheon-like stack (stack-pantheon.yml), similar to existing acquia-like stack

[ultimike]

I'd love to see other Drupal hosting stacks available (especially Pantheon).

I'm not entirely sure what is involved in creating a new stack, but I figured I'd open an issue and see if others are interesting seeing this.

thanks,
-mike

[achekulaev]

Cloud hostings integration is so much more than just a stack. It would require a whole subset of commands to authenticate, pull or deploy files there, get status leaving alone the fact that it's not a local stack so changes the whole way fin should interact with containers.

I don't think it's a short time goal at this moment. More like a 2.0 release target.

[ultimike]

Well, I wasn't thinking about all the authentication, push/pull stuff - maybe I wasn't using the right terminology. What I was thinking of is just a set of containers that closely match Pantheon hosting - Nginx, MariaDB (or whichever DB engine they use), Solr, etc...

…

-mike

On Thu, Mar 9, 2017 at 2:10 PM, Alexei Chekulaev ***@***.***> wrote: Cloud hostings integration is so much more than just a stack. It would require a whole subset of commands to authenticate, pull or deploy files there, get status leaving alone the fact that it's not a local stack so changes the whole way fin should interact with containers. I don't think it's a short time goal at this moment. More like a 2.0 release target. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#143 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpdkZubZBg18Qy41i96zZVETKHdQUo2ks5rkE6ugaJpZM4MYQBF> .

[lmakarov]

Putting together just the stack (a list of matching services in containers) should not be a huge deal.
However, to make it all round and shiny and claim a support for Pantheon (including tools and workflows) is a lot more work, as @achekulaev mentioned.

Let's wait and see how many thumbs up this request will get over time.

[ultimike]

Yeah, that's exactly what I had in mind. It's not that big of a deal to manually do Git pulls/pushes, or update the local DB. The containers would be more than sufficient in the short term. thanks, -mike

…

On Thu, Mar 9, 2017 at 2:35 PM, Leonid Makarov ***@***.***> wrote: Putting together just the stack (a list of matching services in containers) should not be a huge deal. However, to make it all round and shiny and claim a support for Pantheon (including tools and workflows) is a lot more work, as @achekulaev <https://github.com/achekulaev> mentioned. Let's wait and see how many thumbs up this request will get over time. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#143 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpdkd0jP4JzX8RFKmRc93A9SgJHrFSoks5rkFRlgaJpZM4MYQBF> .

[Ky1e]

I'd like to see this as well. 👍

[achekulaev]

@ultimike oh I see. Just pantheon-like stack. I misunderstood you then. Let me rename ticket back.

[mattpaz]

It'd be great to include the external libraries too ...
https://pantheon.io/docs/external-libraries/

Maybe we'd have something like ...

DOCKSAL_STACK="pantheon" for stack-pantheon.yml
DOCKSAL_STACK="pantheon-extended" and stack-pantheon-extended.yml

That'd give folks an option of a leaner stack or a more complete environment match.

Looks like the folks behind Kalabox were looking into rounding out their stack too ...
https://github.com/kalabox/kalabox/issues/418

Thanks for the great work on this!

[briancoffelt]

A Pantheon-specific stack would be great!

[lmakarov]

If anyone from the Pantheon users here wants to take a lead and put together a high level overview of what the stack should look like (services, libraries, binaries, versions, etc.) - that will be a good start.
So far I've found this, but it does not cover everything: https://pantheon.io/docs/application-containers

I think we major difference between Acquia and Pantheon in terms of services used is Nginx vs Apache and Redis vs Memcached. What else?

[kclarkson]

I am actually curious which company hosts more sites. Seeming Pantheon is a huge host this would help get more people using docksal. Thumbs up for this!

[ultimike]

@lmakarov Here's what I've found on https://github.com/kalabox/kalabox-app-pantheon/tree/v2.1/app/dockerfiles/pantheon-solr - I'm using Kalabox as the model because - from my understanding - they are pretty much at parity with Pantheon's servers.

• mariadb:10.0
• nginx:1.8.1
• redis:2.8

There's some additional stuff there, including what to my untrained eyes looks like a tweaked version of Solr (https://github.com/kalabox/kalabox-app-pantheon/tree/v2.1/app/dockerfiles/pantheon-solr), but I think that these are the basics.

-mike

[davidneedham]

https://hub.docker.com/r/kalabox/pantheon-appserver/

[lmakarov]

Unofficial Nginx support in Docksal
https://blog.docksal.io/unofficial-nginx-support-in-docksal-42bfab10548e

[n00b21337]

What does this mean
"Requires a hack to suppress a script in wodby/drupal-nginx - see https://blog.docksal.io/unofficial-nginx-support-in-docksal-42bfab10548e"

Where do we put this script and how it should be run?

[lmakarov]

@adriadrop see the details in the linked blog post:

cd <project-root>
mkdir -p .docksal/services/web
echo 'echo "dummy script"' > .docksal/services/web/init_volumes
chmod +x .docksal/services/web/init_volumes

This dummy script version is mapped into the container to suppress the original script.

[n00b21337]

I really dont get from your posts where this script should be put and how it should be called, can you please just directly say :)

[lmakarov]

@adriadrop

1. In your project, create a file in .docksal/services/web/init_volumes (init_volumes is the file name)
2. In that file, put echo "dummy script"
3. Make the file executable - chmod +x .docksal/services/web/init_volumes

The file is then mounted into the nginx web container:

version: "2.1"

services:
  web:
    image: wodby/drupal-nginx:8-1.12-4.0.4
    volumes:
      # Suppress the permissions fixer script in wodby/drupal-nginx
      - ${PROJECT_ROOT}/.docksal/services/web/init_volumes:/usr/local/bin/init_volumes
    environment:
      - NGINX_BACKEND_HOST=cli
      - NGINX_SERVER_ROOT=/var/www/${DOCROOT}
    working_dir: /var/www/${DOCROOT}

[n00b21337]

So what is confusing is that by default there is already ".docksal/services/web/init_volumes/" where init_volumes is directory. Also on some other post there was mentioned "fix-permissions.sh" to be created. So all of this was confusing. Ok I will try like you said above. thanx

[lmakarov]

The reason you have init_volumes present as a directory is because you had the stack started before there was this file in place (as a file). Docker creates an empty directory for mounts that do not exist on the host. Remove the stack, delete the init_volumes folder, put that dummy script file instead of it and launch the stack.

I updated the blog post to not mention fix-permissions.sh. wodby/drupal-nginx used to call it that way, but then renamed to init_volumes.

Note: this whole approach is no way an official recommendation. Just a hack to give enthusiasts something they can play with.

[n00b21337]

Thanx on help. Its more clear now.