The drush container is separate because the app container will be scaled in number
so we can have a single target for SSH for drush
@johnstorey Please don't feel stupid! we should explain this better in the docs...
yeah once i get up & running I’ll get a better feel for actual use
scottrigby @scottrigby nods
I do not believe the current terra/drush image is set up to conveniently use private files. If I understand everything correctly, the Drupal installation is mounted as a volume on /usr/share/nginx/html. Nginx is configured to make that the web root directory. Would it be better to have the App put Drupal in a sub-directory, mount the sub-directory, and add a 'private' directory mounted to some appropriate spot in the image?
docker-compose is now fully overridable: https://github.com/jonpugh/terra-wordpress/blob/master/.terra.yml
@jonpugh sorry I've slowed down lately. My brain's been trying to make sense of certain arch issues
Good to see you, sir.
I got distracted by morons from the internet, but now I'm back to it.
@jonpugh Basically, we're going with Kubernetes initially. We still want to be PaaS agnostic as much as possible, but Kubernetes is the first target, as it'll work for the most situations (and already handles clustered file storage and the associated craziness out of the box). We'll have a REST API that will pass things off to the task queue (likely Celery or Rabbit MQ), and eventually the backing PaaS. We'll also have a build system - probably going to depend on buildpacks for web applications (so that we don't have to write our own container building logic, and so that more stuff can be reused from other communities), and something like docker compose to define service dependencies (mysql, memcache, etc) (note, though, that it won't actually be docker compose - we don't want to work directly with the docker daemon, especially since Kubernetes and other systems have their own way of doing things).
We're not going to handle the local dev story at all for now, though. Terra is probably a good fit to fill that gap. Not sure how much you want to focus your efforts on that particular area, but as a general point of interest, the two ops teams that I've talked to (one at Stanford and one at Micron - conversation with the NBC ops team is pending) would generally be disinclined to trust a tool that claims to do everything. They've had consistently better luck with tools that do one thing well.
It may turn out that we eventually ditch the idea of PaaS agnosticism (or at least plans for writing backends for other PaaSes as part of the core project), though. Kubernetes does a lot of really good things, and if we're in the business of promoting best practices as a project, then we want to promote the best tools for the job.
In any case, you may have noticed some overlap with the summary above and what your plans are for Terra (and likely some differences). I think parts of Terra make sense as a component of Aegir if you're up for it (for instance, the REST API that you mentioned here: terra-ops/terra-app#67). Having the REST API (And more generally, the most of the production deployment bits) handled by Aegir reduces what Terra needs to be responsible for. Ditto with the UI. Not sure what direction you were planning to go with that, though.
@jonpugh ^
@jonpugh Alright. tbh, I was hoping that it wouldn't continue to be a "you" and "us" separation in the long term (or even moderately short term). We both have the same goals, and the only difference is how the production deployment parts work. This has been my attempt at extending the olive branch, as they say. I'd personally still like to work with you on fixing application deployment, but if you want to keep going your own way, that's fine too.
@jonpugh No, I know, but the overlap in people that are working on the plan that we discussed and agreed on at NYCcamp and the people that are working on Terra is either zero or close to it, afaik. What I was suggesting (in a roundabout, less than direct way) is that if Terra had a more narrow focus, we (the combination of the Aegir and Terra communities) can solve everything from dev->production in a much more comprehensive way.
@jonpugh So would we :) In any case, I'm not sure if you've seen the emails, but we're doing a weekly Aegir checkin on Thursdays at 2pm UTC via Google Hangout. I'll leave some feedback in that issue above. Hopefully we can converge on something that will be beneficial to everyone.
I think docker-machine is totally the way to go
@jonpugh it's vanilla Kubernetes, though. They have a Drupal frontend for it, but it's pretty simplistic at this point.