Provide Support for Drupal-based Apps

[RonWilliams]

A large contingent of IT users in the Federal Government operate Drupal based applications. Our team would like to streamline the deployment process for operating Drupal sites on cloud.gov. A rough outline is below:

• [ ] Develop sample app for Drupal using native filesystem deployments (ex EFS)
• [ ] Implement common php and Drupal caching techniques within buildpack (ex. opcache and redis)
• [ ] Document process for use of sample app
• [ ] Document process for import of existing Drupal app from legacy provider or Git Repository

[RonWilliams]

@karareinsel @eddietejeda -- Looking for feedback. Will add to the triage list once we're happy with the path forward.

[karareinsel]

Would we need to create the EFS broker first before tackling the first AC? Or is creating the EFS broker the first AC?

[spgreenberg]

The viable path within our current SSP is to package Drupal runtimes as a bosh release and deploy these types of applications in VMs. CF is not a viable option for applications requiring persistent file systems.

[tammersaleh]

I think, in general, it'd be better to present required outcomes to the engineering team, and allow us as a group to figure out what the most effective technical solution would be to get there. For this one I agree with @spgreenberg: I think it'd be easier and more sustainable to run a Drupal BOSH release as a services product than to try to get EFS on CF working reliably.

[pburkholder]

Supporting Drupal as a Bosh release would likely require an SCR as we'd then be offering "Drupal-as-a-Service" within cloud.gov. Is that the route we want to go, or do we want to support Drupal as a 12-factor app with no EFS and use S3 as demonstrated in https://github.com/cloud-gov/cf-ex-drupal8 ?

On Wed, May 13, 2020 at 1:45 PM Tammer Saleh notifications@github.com wrote:

I think, in general, it'd be better to present required outcomes to the engineering team, and allow us as a group to figure out what the most effective technical solution would be to get there. For this one I agree with @spgreenberg https://github.com/spgreenberg: I think it'd be easier and more sustainable to run a Drupal BOSH release as a services product than to try to get EFS on CF working reliably.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cloud-gov/product/issues/1368#issuecomment-628144944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHWCWFTNCXAC5DSPBO3NLRRLMEBANCNFSM4M7MUSRA .

--

Peter Burkholder cloud.gov compliance & security | co-lead DevOps Community of Practice https://digital.gov/communities/devops/

Solutions https://www.gsa.gov/about-us/organization/federal-acquisition-service/technology-transformation-services/tts-solutions | Technology Transformation Services https://join.tts.gsa.gov/tts-offices/

|

GSA http://www.gsa.gov/portal/category/100000

202-709-2028 <(202)%20209-2028> | peter.burkholder@gsa.gov peter.burkholder@gsa.gov

| pronouns he-him https://www.mypronouns.org/he-him Free/Busy Calendar https://calendar.google.com/calendar/embed?src=peter.burkholder@gsa.gov

[tammersaleh]

Thank you, @pburkholder! I wasn't aware that Drupal had s3 support that didn't rely on FuseFS. Yes, this solution is much simpler, and (I believe) one that our customers can roll out without any further support on our end.

[RonWilliams]

Existing Drupal apps using the default filesystem have a significant (near impossible) migration burden to the S3 based filesystem. While Drupal's S3 support works for new sites, it's problematic for migrating existing sites. We need an approach that supports new and existing sites migrating to cloud.gov.

[tammersaleh]

I don't think we should let perfect win over good in this case. This gives us an answer to new Drupal installations. For existing sites, it still seems like it would be more worthwhile to invest in a migration tool rather than attempting to produce and support an EFS broker. I'm very uncomfortable running such a broker in a production CF installation -- I'd feel better about it if we had examples of other teams running it in anger.

[RonWilliams]

Agreed -- perfect should not win over good, but we need to meet the business requirement. Our active potential opportunities come from agencies with existing Drupal deployments.

[spgreenberg]

@pburkholder This is great. I didn't know this was here.

I do think the right long term solution is to broker access to GKE for any containerized workload. The bosh suggestion is based on the requirement for an actual file system and the goal of being as close as possible to our existing tech stack.

[karareinsel]

Would it be helpful if we reframed this as being able to support customers who need to write to a local file system - which includes Drupal, Wordpress, Atlassian, Adobe Experience Manager, etc.? While the original need came out of customers with existing Drupal sites, the need isn't specific to Drupal. If something like an EFS broker could help many prospective customers (not just Drupal customers), does that change how we look at it? If there are technical concerns that an EFS broker would be janky/not a good solution/would increase our technical or compliance burden, then I think that's worth exploring that. If it's philosophical, then let's talk about that too. Building for one customer can be risky; but that risk is greatly mitigated when what we're building answers a common need of many customers. Just my 2 cents.

[tammersaleh]

A generalized approach that helps all customers would be wonderful. My concerns aren't philosophical, but practical. I haven't seen a team use any of the filesystem brokers for Cloud Foundry, and I worry that they will be a large operational burden and cause instability for our customers. OTOH, I know many companies running stateful workloads on k8s.

We can mitigate these concerns by finding teams that can give us war stories about running container-mounted filesystems on CF, and by kicking off a project to evaluate the stability ourselves. If we did the latter (which I'd be 👍 to), then we would want to make sure we really push it. Finding operational issues through synthetic tests like this is notoriously hard - yet those issues always seem to come out in real production 🤷

[tammersaleh]

Maybe someone with more historic knowledge than I might have war stories that could assuage my fears. /cc @mxplusb @mogul @bengerman13

[tammersaleh]

After a little digging, it looks as though we spent some energy removing the NFS broker before I started on the team: https://github.com/cloud-gov/private/issues/89

[mheadd]

Thats a good find. I'd be interested to know more about why we abandoned that work. Was it to "...resolve compliance findings and improve our security posture," or were there other reasons, like those @tammersaleh mentioned ☝️ ?

[RonWilliams]

My understanding is we removed NFS because it was only used by the cloud.gov team and the underlying dependencies had vulnerabilities. Given the limited use of the NFS broker, it made sense to remove entirely. @bengerman13 should be able to confirm or correct the history.

[pburkholder]

@sharms is also in TTS and might have more insight into what the volume issues were.

That said, once we're past project bedrock, it might be worthwhile to weigh the persistent-filesystem feature against other customer-facing features on a feasability vs impact map (or some other weighting).

And if we do want to make a play for Drupal customers, I'd be curious about the FS to S3 migration issues mentioned earlier. If they are truly insurmountable, then so be it, but if there is a viable path then I think we'd be a in place to offer a best-in-class Drupal experience without an EFS dependency.

[RonWilliams]

Thanks for the lively discussion and feedback. There's more refinement on this idea based on customer needs. Let's continue solutions discussions once customer needs are more clearly defined.