Increasingly, modern workflows for developing/deploying/maintaining sites use a machine image based model. These images jump start the process of getting a site up and running by including the appropriate LAMP stack, up to date versions, and in some case other common packages or resources that are very commonly installed.
Examples of such packages exist across most common cloud hosting marketplaces:
Right now - when a site owner goes to Drupal.org - we do not present, document, or link to any options for this kind of deployment workflow.
Similarly, when a site owner goes to any of those marketplaces directly, the only Drupal options which exist are unofficially maintained images, which we cannot be sure follow best practices.
Maintaining official, opinionated Drupal images across these cloud providers and linking to them from Drupal.org as a co-equal method of using Drupal would ensure that the Drupal project meets the expectations of site owners who work in this way.
To successfully manage this project we would need the following:
hestenet (he/him) [5 days ago]
Hi all! @geerlingguy pointed me in the direction of this channel to maybe find some folks who might be interested in an initiative.
The DA Staff and Core Maintainers (and a few others we’ve reached out to) have been chatting on and off over the past months about the concept of a ‘maintainer for cloud images’
Effectively - this would be a volunteer looking to take on the responsibility of using a tool like Packer to maintain recommended Drupal images on various cloud provider platforms(updated as needed as new releases occur) - which we could then point to from Drupal.org.
Jeff suggested that some of you in this channel had been talking about similar ideas! If you have thoughts around this I’d love to hear them and maybe set up a more formal conversation with anyone especially interested.
Feel free to respond to this message in a thread if you have any thoughts! Thanks all.
siva_epari [5 days ago]
Sounds interesting. I would definitely love to take this up, but am trying to understand the different responsibilities associated with such volunteering:
1. What does "various cloud provider platforms" mean? Docker images can be used on any platform. There might be different images based on Operating Systems
2. Do we have a central repository to maintain the Packer scripts? How will they be synced with Official Docker image https://hub.docker.com/_/drupal ? I think, we need to look into how other Free Software organizations are communicating/collaborating with Docker hub team
3. In this channel, much of the conversation is about building kubernetes operators for Drupal. Which are completely different from Docker images.
4. Can you clarify on what you meant by "which we could then point to from Drupal.org."? Is it something like a backlink to drupal.org?
hestenet (he/him) [5 days ago]
1. I mean deploying to AWS, Google Cloud, Digital Ocean - etc - pushing out to those various platforms so people using those platforms can find the proper image that’s actually maintained by a volunteer.
2. We don’t currently, so far as I know - there are a bunch of Packer scripts maintained as part of DrupalCI but we’d probably start a new project/repository on D.O for this, I suspect
3. Yes - I think this is only *sort of* related to the kubernetes conversations - but I think Jeff suggested I post here, because this channel has people with the related expertise.
4. Sorry - but “Point to from Drupal.org” I mean having a page on Drupal.org itself (or maybe something on the download page) - that says something like “Prefer to deploy Drupal on a cloud provider? - here are the recommended images” which points to these recommendations we are maintaining.
cyberswat [5 days ago]
@hestenet (he/him) I’d like to see more of a proposal around this as it does raise a host of questions.
cyberswat [5 days ago]
It sounds like you have a plan in mind and are looking for someone to execute it.
Jason Roberts [5 days ago]
Hey @hestenet (he/him) I like this idea. I've been looking into https://buildpacks.io/docs/
cyberswat [5 days ago]
Generating docker images so they tie into your CI/CD should be fairly straightforward, but may not provide the type of flexibility we have come to understand as a result of working with kubernetes.
hestenet (he/him) [5 days ago]
I’m not sure if I have plan so much as an outline of one - but sure - can definitely try and document the idea in a little more detail. I’m not a subject-matter aspect when it comes to machine image management - but I do have a sense of what some people have asked about in the past - so I’m sort of trying to consolidate those into an outline for this idea :sweat_smile:
cyberswat [5 days ago]
Would you be open to a zoom call with some of our team?
cyberswat [5 days ago]
That might make things a little easier to walk through some of our thoughts.
hestenet (he/him) [5 days ago]
Sure - I’d be happy to. My calendar availability is here if that would help finding a slot: https://calendly.com/hestenet/worldwide-timeslots
hestenet (he/him) [5 days ago]
^^ Same offer if anyone else would like to chat :smile:
cyberswat [5 days ago]
fwiw if you have some extra time and are curious about this group https://www.youtube.com/watch?v=KlXN2vbOHAM&list=PL0T6TX9bw-Jfibva7p5c0_... is probably a good place to start (edited)
richo [5 days ago]
I’d be keen to create those images, sounds like fun. As pointed out, some kind of ‘official wishlist’ would be great as the devil is in the detail with this sort of stuff.
It would also be good to know how this might tie into any potential Drupal official Docker images in future, so that common decisions can be made where practical.
As just one example, should the cloud image (via Packer) use Nginx or Apache. If it uses one of these, I think any potential Docker image should use the same so there’s a common baseline.
I’d also like to suggest taking this one step further and bundling the cloud image and it’s associated components into some Terraform scripts so people can go that one step further not just launch Drupal, but also have a starting point when considering things like how to take those image into production.
richo [5 days ago]
Or are you looking for the maintainer to make these sorts of decisions a bit more independently?
hestenet (he/him) [5 days ago]
I think those are all good thoughts and ideas - I think it’s a little bit off both.
hestenet (he/him) [5 days ago]
Likely we need someone with a strong vision to propose some ideas for those baselines - and likely post that out into an issue to ensure it has the appropriate community buy in.
hestenet (he/him) [5 days ago]
I think pinning to what we put forward as the general system requirements/recommendations in current documentation would be smart. We do want to avoid having this be too much more of a special snowflake compared to what you get with a tar ball or composer.
hestenet (he/him) [5 days ago]
The terraform idea could be really valuable - that has been one of the struggles with this idea in early discussions - Drupal is not a thing you use out of the box without customizing to your particular needs.. yeah
richo [5 days ago]
yeah - my personal experience with tutorials/boilerplates has been that I like the ones that give me everything I need get started, but I _love_ the ones that give me an indication of where to go next
richo [5 days ago]
I’ll put a prototype together in the next few days for an EC2 image and we can go from there?
richo [5 days ago]
I made some youtube videos for our Tokaido stuff. I’d like to do something similar for this, too.
https://www.youtube.com/watch?v=Q72H_B8sVNw (edited)
andypost [5 days ago]
I bet this images already exists and managed by cloud providers like https://bitnami.com/stack/drupal/installer
Not sure that more then existing docker images makes sense, because each final site has variations of deploy to specific infra
andypost [5 days ago]
Another option is https://www.scaleway.com/en/imagehub/drupal/
Scaleway
Drupal
Drupal is an open source content management platform powering millions of websites and applications.
andypost [5 days ago]
On other hand d-org infra already maintain images and scripts to extend for cloud providers, which are mostly canonical source of core Tests (edited)
hestenet (he/him) [5 days ago]
Yeah, exactly - these images already exist in an ad-hoc way in various places - but we don’t know if we can confidentally say ‘yes this is an image that is updated promptly for security releases - yes this is an image that provides a good starting point’
hestenet (he/him) [5 days ago]
I think that’s why we need some kind of volunteer maintainer who can help coordinate that side of things - just as a quality check and to ensure these things follow best practices.
hestenet (he/him) [5 days ago]
@richo that sounds great!
andypost [5 days ago]
OTOH it means to stick on some binaries which is hard to extend
andypost [5 days ago]
Core has quickstart command so starterkit is already packaged and needs only composer & some php
richo [5 days ago]
Do you have a link to that? I’m not familiar with it
andypost [5 days ago]
https://www.drupal.org/node/2969396 →
richo [5 days ago]
thanks :slightly_smiling_face:
richo [5 days ago]
but that assumes you have a server ready to go and know what you’re doing with it
andypost [5 days ago]
So makes sense to extend docs at
https://www.drupal.org/docs/8/install/drupal-8-quick-start-command →
with cloud usage) (edited)
Drupal.org
Drupal 8 Quick Start Command
The quick-start command is new as of Drupal-8.6.x. It is not intended for production use. However, it will install and run Drupal using PHP's built-in web server on your own computer. Important: the quick-start command is intended only for launching a local demo version of Drupal. If you need to install Drupal 8 for production use, see instructions in the rest of this guide
May 12th, 2018
nick_schuch [5 days ago]
Hey @hestenet (he/him)! We currently maintain a set of images for Apache / Nginx based deployments. These are Alpine images with our own PHP package repositories to keep up with the php release cadence. Would love to work with the community on a common base set of images.
nicksanta [5 days ago]
What is intended to be put in these images? (edited)
richo [5 days ago]
I’m pretty sure @hestenet (he/him) is talking about cloud images, ie EC2 AMIs etc, not docker images
nicksanta [5 days ago]
Question still stands
nicksanta [5 days ago]
I've seen some questionable stuff over the years, baking drupal core into amis etc..
nick_schuch [5 days ago]
Very true, my motivation is to lower the bar for "what extensions and webserver best practices do I need"
nick_schuch [5 days ago]
while also having a secure image
nick_schuch [5 days ago]
even just best practice guides around it
8thom [4 days ago]
might be worth looking into https://cnab.io/ a specification that is meant to be agnostic to the underlying technologies
cnab.io
CNAB: a spec for packaging distributed apps.
Cloud Native Application Bundles facilitate the bundling, installing and managing of container-native apps — and their coupled services.
hpinheiro [24 hours ago]
Bitnami does have some https://bitnami.com/stack/drupal/cloud/aws/amis but their highly opinionated with a lot of their custom scripts - although they might be good to see what they got configured in them :slightly_smiling_face: - most of the public clouds use theirs for their one button click here to launch drupal stuff
richo [19 hours ago]
@hestenet (he/him) Based on the feedback in this thread, I’m not sure if I should get started with a prototype or wait until some more requirements are gathered that I we can build from? I’m happy to get started, but there’s a lot of ways to slice this, and I want to make sure I’m not starting down a path that nobody else likes :slightly_smiling_face:
hestenet (he/him) [7 minutes ago]
Coming back to this thread since I was out for a long weekend. (I should also archive this thread I think…)
hestenet (he/him) [2 minutes ago]
So clarifying a couple of points above:
1) Yes, talking mostly about cloud images rather than docker images/kube operators/etc. - although perhaps those could be part of this initiative or a follow-up one eventually.
2) Re: what’s in the images and re: being opinionated — I think these are interrelated questions and need to be defined — i.e: it’s not really possible to make an ami that is not opinionated, so that opinion should be well defined - preferably in a public issue - and ideally follow the pattern of Drupal’s documented system requirements.
3) ^^ I think solving some of the bad habits that exist with the amis that are just floating out there already in terms of what’s baked in, and how they’d be updated, etc would be an important part of that process as well. (edited)
hestenet (he/him) [2 minutes ago]
I suspect the right next step might be to start some issues to define some of this…
hestenet (he/him) [1 minute ago]
@richo I think getting started in some form may not be a bad thing - but maybe that should be in the form of ‘documenting out a proposal for doing this’ rather than an actual technical prototype?
As I’ve said above, I’m not enough of an expert in machine images to get too much more detailed than the high level ask I’ve outlined so far… so that’s definitely going to lean on community input.
Postponed: needs info
11.0 🔥
other
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.
Since it has been quiet on this issue for about 6 years, checking in to see if this is still valid.
Is there interest in this feature request?