Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate deployment of specs.webplatform.org #104

Open
1 task
renoirb opened this issue Jan 28, 2015 · 5 comments
Open
1 task

Automate deployment of specs.webplatform.org #104

renoirb opened this issue Jan 28, 2015 · 5 comments

Comments

@renoirb
Copy link
Member

renoirb commented Jan 28, 2015

Once we migrated specs.webplatform.org to the new DreamCompute environment #90, we gotta automate its maintenance with what @darobin created so we can make it part of our infrastructure.

Tasks

Related

@darobin
Copy link

darobin commented Jan 29, 2015

All it needs for the moment is rsync and a stable SSH entry point. Oh, and the nginx needs to be as stupid as possible (i.e. not run PHP). Basic HTTP caching (as opposed to aggressive CDN caching) is fine, if there is CDN caching I need a way to purge.

In fact we could make this even simpler and just have specs.wpo be a proxy to the build system. I could easily set this up, and that way there is no need for integration; it is much simpler.

@renoirb
Copy link
Member Author

renoirb commented Jan 30, 2015

All it needs for the moment is rsync
Ok

rsync is what I do everywhere anyway, even with salt. The question might be in which direction do you do things; Where you build? In which direction you rsync?

and a stable SSH entry point.

I’ll sync with you soon about the issue you had. Everything will be through a jump box.

Oh, and the nginx needs to be as stupid as possible (i.e. not run PHP).

That’s what I’ve done in the new setup.

Basic HTTP caching (as opposed to aggressive CDN caching) is fine,

I’m not sure what you want. I showed you how to purge cache.

if there is CDN caching I need a way to purge.

Let’s talk about it after the migration.

In fact we could make this even simpler and just have specs.wpo be a proxy to the build system.
I could easily set this up, and that way there is no need for integration; it is much simpler.

I haven’t forgotten you. I’m still upgrading our MediaWiki version.

Let’s touch base next week. I’ll try first to replicate everything so you’ll tell me if I missed something.

@darobin
Copy link

darobin commented Jan 30, 2015

I build on my box, which I can break. I rsync to the server. That is why I only need a static server.

Concerning cache purging I know how to do it with Fastly and it is deployed in production. But since you're moving setup I assume that won't work any more.

@renoirb
Copy link
Member Author

renoirb commented Jan 30, 2015

Just to confirm if I got it right.

There are two VMs involved.

  1. The one that Fastly reads from and that you connect through ssh via an IP address
  2. The other called deployment.webplatform.org

So, are you saying that you build static pages from 1, and that from that same VM you send things through rsync to 2?

@darobin
Copy link

darobin commented Feb 2, 2015

I don't know. I am using the IP address you gave me as the one serving specs.webplatform.org. That is all I use.

@renoirb renoirb removed their assignment Sep 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants