-
-
Notifications
You must be signed in to change notification settings - Fork 260
Build instructions for how to bootstrap and maintain Drupal 8 codebase + container #111
Comments
One quick question I want to jot here while it's on my mind: Is it possible (if so, how?) to make a truly cumalative git-repo-based container image where new tags/hashes/versions only contain a new layer with the changes from the latest git hash (rather than each new container image containing the entire codebase as a layer, meaning every image will be at least as big as the size of the codebase)? I know that was one of the whiz-bang intro-to-Docker-101 level things I remember hearing about... but in practice most places seem to add a For a lot of poorly-architected codebases (I've seen them in the 1-5 GB range!), that means giant blobs of images for every single commit, ever! |
#108 is complete, so we have a local private Docker registry with which images can be managed locally. |
The main thing that's annoying—if you do a Would like to make it so the settings.php can be dynamically generated, or gets info from environment variables (the latter seems better, and the vars for DB connection are already there). |
Working on geerlingguy/drupal-container#12 as a stop-gap, to hopefully allow multiple replicas of the Drupal container to run and use the same database connection and not do... weird things. |
I think the approach I'm going to take is:
Also going to move #133 into that project's repo, since it literally contains all the contents of the Pi Dramble website now (yay!). And soon I'll also need to install that site on the running cluster/Pi itself and finally step away from Bartik :) |
Just a scratchpad for potential changes to make the Drupal Example for Kubernetes to work as a drop-in swap for the current container:
I also will need to make the |
To get the registry working correctly, I'm going to need to knock out #114 as well... |
Registry is working correctly now. So next steps (jotting since I'm folding up shop for the night):
|
Looks like I'll have to do a few more things to the Drupal for Kubernetes project to get it fully ready to run in the Kubernetes environment... getting:
|
I had to manually edit settings.php: $config_directories['sync'] = '../config/sync';
$databases['default']['default'] = array (
'database' => getenv('DRUPAL_DATABASE_NAME'),
'username' => getenv('DRUPAL_DATABASE_USERNAME'),
'password' => getenv('DRUPAL_DATABASE_PASSWORD'),
'prefix' => '',
'host' => getenv('DRUPAL_DATABASE_HOST'),
'port' => '',
'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
'driver' => 'mysql',
);
$settings['hash_salt'] = getenv('DRUPAL_HASH_SALT'); Then I had to drop all tables and reinstall Drupal:
|
Milestone: I have Drupal for Kubernetes running on the cluster: But I need to fix the I thought I had already figured this out elsewhere, but I'm not seeing where I did so :/ |
Ah... I did set this up over in the Problem is, that's only run for the downloaded Drupal tarball, not for the Drupal for Kubernetes codebase! So I'll need to create a template settings.php or something like that for use in production. |
Fixed over in geerlingguy/drupal-for-kubernetes#10 — local testing is good so far! Next up, I need to start testing this on the real Pi cluster... and test building the image on ARM32 (right now I've only tested on AMD64). |
Installing on a freshly-reset set of Pis now. Apparently Docker 18.09.2 has not yet been released for Raspbian:
So I have to stick to (See: |
Weird, now I'm running into:
|
Dangit... apparently this has to do with the PHP 7.0.33 version that is present on the ARM version of I'll have to look at upgrading to 7.1 or later. See: acquia/blt#2660 (comment) Trying https://getgrav.org/blog/raspberrypi-nginx-php7-dev — but actually considering building/using a |
Could also use one of my favorite repos—apparently Oerdnj supports ARM now, who knew? oerdnj/deb.sury.org#579 |
Upstream issue: geerlingguy/drupal-container#17 |
PHP 7.3.x/buster did not work out of the box, so trying Ondrej Sury's repos now. |
Still working on these issues through the drupal-for-kubernetes and drupal-container projects... |
Build pipelines are always amazing until there are little failures in multiple stages. |
Fixed the upstream issues, running PHP 7.2.x now, and the site loads from the Pi Cluster just as well as it does from the local Vagrant/VirtualBox cluster, yay! |
I've added all the build directions to the Drupal for Kubernetes repo over here: https://github.com/geerlingguy/drupal-for-kubernetes/tree/master/docs |
So here's where a lot of the rubber meets the road...
geerlingguy/drupal
image from Docker Hub.drupal-project
if I need more modules and Composery delights.99.9% of all the blog posts, docs, etc., assume you're just mounting the codebase inside the container using a Docker volume / bind mount / etc.
But I want to document (and start using in my personal infra, quite frankly!) a process whereby:
spec.template.spec.containers[0].image
in thedrupal8.yml
manifest to point to the new tagged image or latest hash).I might not go the full distance and automate everything 100% inside this project's codebase; but I do want that workflow to be enabled easily, and I want at least one or more of the following:
kubectl apply
of the changed image.The text was updated successfully, but these errors were encountered: