| Labs Project Tested | production migration (T137890) |
| Site/Location | eqiad |
| Number of systems | 1 |
| Service | https://doc.wikimedia.org |
| Networking Requirements | ssh/rsync from contint1001.wikimedia.org (208.80.154.17), HTTP for Varnish caches (text-lb?) |
| Processor Requirements | 4 |
| Memory | 4GBytes |
| Disks | 150GBytes |
| Other Requirements | Stretch for php7.0 |
https://doc.wikimedia.org/ hosts documentation and coverage report for several softwares. It is currently hosted on contint1001.wikimedia.org which also hosts Jenkins, Zuul and Docker for the deployment pipeline.
The content is generated by CI jobs on WMCS instances which rsync the artifacts to a proxy instance on WMCS: integration-publishing02. A job is then triggered on contint1001 to fetch the artifacts and copy them to Apache docroot effectively publishing them.
When overhauling the CI stack in 2016 we have identified the need to move doc.wikimedia.org to a different machine than the one running the CI stack (Jenkins, Zuul). Notably:
- only doc.wikimedia.org requires php however the machine runs on Jessie and lacks php7.0. That breaks oojs demos and probably other ones T206046
- although content is code-review +2 by project owners, the code is running on a production machine that has jenkins/zuul/docker which might be a security breach. It seems safer to have the code executed on a different machine.
- whenever the CI machine is under maintenance, doc.wikimedia.org is no more available.
contint1001.wikimedia.org /srv/org/wikimedia/doc occupies 32GBytes. I have requested 150GBytes to accomodate for the operating system and potential future growth.
4CPU/4GBytes RAM sounds sufficient. There is not that many server side activities to be expected. Most of the content are static files.
We need it to be Stretch to get php7.0.
If at all possible, I would like the instance to be fairly isolated from the rest of the network (prevent outgress).
We would need bacula backup.
The envisioned flow:
