Page MenuHomePhabricator

Ready-to-use Docker package for MediaWiki
Closed, ResolvedPublic

Assigned To
Authored By
Mglaser
Mar 16 2015, 1:19 PM
Referenced Files
None
Tokens
"Like" token, awarded by freephile."Love" token, awarded by xSavitar."Love" token, awarded by dbarratt."Like" token, awarded by Calexit."Like" token, awarded by ssastry."Love" token, awarded by greg."Like" token, awarded by Physikerwelt.

Description

GOAL:
Get an idea whether Docker is a feasible means of deploying MediaWiki to 3rd parties.

In order to do so, we build a MediaWiki package that runs inside a Docker container and can (theoretically) be used for productive MediaWiki instances.

This should ideally include

  • a vanilla MediaWiki
  • some Commonly used extensions
  • an extension using a service, e.g. VisualEditor

An upgrade path without data loss should be provided.

Current instructions: https://phabricator.wikimedia.org/diffusion/MWVA/browse/master/support/README-lxc.md

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

There is a basic MediaWiki docker image at https://hub.docker.com/r/synctree/mediawiki/. It is using a linked MySQL instance, so doesn't try to bundle several services in a single system (good!). The build tools for this image are available at https://github.com/synctree/docker-mediawiki.

Bare-bones & insecure instructions:

docker run -d --name=some-mysql -e MYSQL_ROOT_PASSWORD=abcd mysql
docker run -d --name some-mediawiki --link some-mysql:mysql -e MEDIAWIKI_DB_USER=root -e MEDIAWIKI_DB_PASSWORD=abcd -p 127.0.0.1:8080:80 synctree/mediawiki

Now, you should see a MediaWiki setup screen at http://localhost:8080/.

My favorite next steps for docker experiments:

  • Set up another container for a Parsoid / RESTBase service (based on a single service-runner process) & add support for linking that to the MediaWiki image.
  • Bundle VE in the MediaWiki image, and automatically configure it to use the RB / Parsoid container.

Further wishlist items:

  • Mathoid, possibly as part of the Parsoid / RB container.
  • Citoid, with Zotero in its own container.

Dependencies:

A very bare-bones proof of concept docker-compose setup is now available at https://github.com/gwicke/mediawiki-docker-compose. Running docker-compose up in a checkout of this repository starts up three containers:

All data is stored outside the containers in host directories, which simplifies backups and container upgrades. The MediaWiki update script is run on each startup, so upgrading should only be a matter of starting up a newer version of the image.

There are still several config issues to be worked out before this is fully functional, but it does look promising so far.

There are still several config issues to be worked out before this is fully functional, but it does look promising so far.

Thanks for this. I've been looking at Docker and this will get me a lot farther.

A few tweaks later RESTBase and Parsoid are now working out of the box. I have also created a wikimedia/mediawiki image based on benhutchin's original Dockerfile.

Next steps:

  • Hook up VisualEditor out of the box.
  • Update to MediaWiki 1.26
  • Forward /api/rest_v1/ to RESTBase.
  • Set up systemd / init scripts to start up the docker-compose setup on boot.
    • Possibly, also provide a systemd-only startup script that doesn't require docker-compose.
  • Add more extensions?
  • Use HHVM?
  • Profit.

The latest version now comes with MediaWiki 1.26 1.27-wmf9 and VisualEditor out of the box. Next up is configuring VE to use RESTBase, enabling Wikitext / HTML switching.

After some more testing on Jessie labs VMs I have now created a simple shell script to start the containers. This drops the dependency on docker-compose and supports older distros, making it even easier to get started.

Steps to a containerized MediaWiki with VisualEditor on Debian-based distros (Jessie or later):

sudo apt-get install docker.io
git clone https://github.com/gwicke/mediawiki-containers.git
cd mediawiki-containers
sudo ./mediawiki-containers start

A brand new MediaWiki instance should now be available at http://localhost/.

In the latest version of mediawiki-containers, there is now support for the (in)famous curl | bash one-line install pattern:

Requirements:

  • Physical hardware or VM, 512mb RAM minimum.
  • Distribution: One of
    • Debian Jessie / 8.0 or newer
    • Ubuntu 15.04 or newer (systemd)
  • root shell for installation

Installation:

curl https://raw.githubusercontent.com/wikimedia/mediawiki-containers/master/mediawiki-containers | sudo bash

Example execution: https://people.wikimedia.org/~gwicke/mediawiki-containers-install.ogv

What is the status of this?
Is mediawiki-containers just an experiement without a future, or is it something that will be supported and updated?

A few tweaks later RESTBase and Parsoid are now working out of the box. I have also created a [wikimedia/mediawiki image]

I cannot see an "Issues" link on the github page, so I am posting here.

I am trying to install this image so that I can have the latest version (the synctree/mediawiki image is 1.24) - but I'm having troubles when I try to access the wiki.

docker run --name wiki --link mysql:mysql -p 9999:80 -d wikimedia/mediawiki

Installs the image and fires up just fine. When I hit http://localhost:9999, the image stops/crashes. So I:

docker start wiki
docker attach wiki

and hit http://localhost:9999 again

Now I have a series of errors (I think they're errors because the container stops afterwards):

PHP Notice: Undefined index: MEDIA_WIKI_DB_TYPE in - on line 4
ln: failed to create symbolic link './COPYING': File exists
ln: failed to create symbolic link './CREDITS': File exists
ln: failed to create symbolic link './[
  FAQ, Gemfile, Gemfile.lock, gruntfile.js HISTORY, INSTALL README 
  README.mediawiki RELEASE_NOTES-1.27, Rakefile, StartProfiler.sample UPGRADE, api.php, autoload.php, 
  cache, composer.json, docs, extensions, images, img_auth.php, includes, index.php, jsduck.json, languages, 
  load.php, maintenance, mw-config, opensearch_desc.php, package.json, phpcs.xml profileinfo.php resources, 
  serialized, skins, tests, thumb.php, thumb_handler.php, vendor, wiki.phtml
]': File exists

(I hope that made sense...)

I had tried with -v "%CD%:/data and I got much the same behavior ... although this time I didn't have to hit the site (might not have had to the first time).

I tried again, this time specifying -e MEDIAWIKI_DB_HOST=mysql I got different errors:

PHP Notice:  Undefined index: MEDIAWIKI_DB_TYPE in - on line 4
[Thu Aug 04 20:22:22.768248 2016] [core:warn] [pid 15] AH00111: Config variable ${MEDIAWIKI_RESTBASE_URL} is not defined
AH00526: Syntax error on line 23 of /etc/apache2/mediawiki.conf:
ProxyPass URL must be absolute!: ${MEDIAWIKI_RESTBASE_URL}/
Action '-e info -D FOREGROUND' failed.
The Apache error log may have more information.

Aaaaaannnnd my last attempt to get this working for now:

d:\vms\mysql>docker run ^
More? --name wiki ^
More? --link mysql:mysql ^
More? -p 9999:80 ^
More? -e MEDIAWIKI_DB_TYPE=mysql ^
More? -e MEDIAWIKI_DB_HOST=mysql ^
More? -e MEDIAWIKI_DB_USER=root ^
More? -e MEDIAWIKI_DB_PASSWORD=my-secret-pw ^
More? -e MEDIAWIKI_SITE_SERVER=http://localhost:9999 ^
More? -e MEDIAWIKI_SITE_NAME="Wiki" ^
More? -v "%cd%":/data:rw ^
More? -d wikimedia/mediawiki
Unable to find image 'wikimedia/mediawiki:latest' locally
latest: Pulling from wikimedia/mediawiki
db77e04b88e1: Pull complete
a3ed95caeb02: Pull complete
26721aea2dfa: Pull complete
ea9f6b320919: Pull complete
87df849d6ef5: Pull complete
8a2082ed385c: Pull complete
b2c45bdb47de: Pull complete
ffdfa96357a7: Pull complete
Digest: sha256:811a2fc4c635950b28f80651380949742dc5a2dd88f836d31407c1dd393f1cb4
Status: Downloaded newer image for wikimedia/mediawiki:latest
e41fc89d70e87d0fa3c1fd4f4932bf7e3a62721e13997719689f6a3400113457

d:\vms\mysql>docker attach wiki
PHP Notice:  Undefined index: MEDIAWIKI_DB_TYPE in - on line 4
PHP 5.6.16-2 is installed.
Warning: Could not find APC, XCache or WinCache.
Object caching is not enabled.
Found ImageMagick: /usr/bin/convert.
Image thumbnailing will be enabled if you enable uploads.
Found the Git version control software: /usr/bin/git.
Using server URL "http://localhost:9999".
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
Warning: Your default directory for uploads (/usr/src/mediawiki/images/) is not checked for vulnerability
to arbitrary script execution during the CLI install.
Warning: The intl PECL extension is not available to handle Unicode normalization, falling back to slow pure-PHP implementation.
If you run a high-traffic site, you should read a little on Unicode normalization.
The environment has been checked.
You can install MediaWiki.
Setting up database
done
Creating tables
done
Creating database user
done
Populating default interwiki table
done
Initializing statistics
done
Generating secret keys
done
Prevent running unneeded updates
done
Creating administrator user account
done
Creating main page with default content
PHP Warning:  mysqli::query(): (42000/3057): Incorrect user-level lock name 'mediawiki:prepared-edit:8ef90d6fe2da950ea6e365958d8d26a7:278ddc0571708cfc40c8d69581bc3364d5742e81'. in /usr/src/mediawiki/includes/db/DatabaseMysqli.php on line 43
Could not insert main page: A database error has occurred. Did you forget to run maintenance/update.php after upgrading?  See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT GET_LOCK('mediawiki:prepared-edit:8ef90d6fe2da950ea6e365958d8d26a7:278ddc0571708cfc40c8d69581bc3364d5742e81', 30) AS lockstatus
Function: ApiStashEdit::checkCache
Error: 3057 Incorrect user-level lock name 'mediawiki:prepared-edit:8ef90d6fe2da950ea6e365958d8d26a7:278ddc0571708cfc40c8d69581bc3364d5742e81'. (mysql)

I am running docker 1.12.0-beta21 (Build 5971) on a windows 10 computer.
The mysql container is built using mysql/mysql-server

I hope we can help each other get this working! I much prefer the clarity of documentation, as well as the range of options you have built!

@TheGleep I reckon the MYSQL version you are using is > 5.7.5

http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_get-lock

MySQL 5.7.5 and later enforces a maximum length on lock names of 64 characters. Previously, no limit was enforced.

Rich

PR #1 updates the Node services container with the latest developments.

Looking at https://github.com/wikimedia/mediawiki-docker, I cannot get a container to run.

[Thu Oct 20 19:35:05.208010 2016] [core:warn] [pid 23] AH00111: Config variable ${MEDIAWIKI_RESTBASE_URL} is not defined
AH00526: Syntax error on line 23 of /etc/apache2/mediawiki.conf:
ProxyPass URL must be absolute!: ${MEDIAWIKI_RESTBASE_URL}/

I see no mention of MEDIAWIKI_RESTBASE_URL anywhere in there.

╭─jivanov@logrhythm01  ~
╰─$ sudo docker run --name mediawiki-mysql -e MYSQL_ROOT_PASSWORD=<snip>  -v /data/docker.mysql:/var/lib/mysql -d mysql:5.6
Unable to find image 'mysql:5.6' locally
Trying to pull repository docker.io/library/mysql ...
5.6: Pulling from docker.io/library/mysql
6a5a5368e0c2: Already exists
0689904e86f0: Already exists
486087a8071d: Already exists
3eff318f6785: Already exists
3df41d8a4cfb: Already exists
1b4a00485931: Already exists
574b57461fa2: Pull complete
9f393afad920: Pull complete
0473f910cd73: Pull complete
08ea9246cb0a: Pull complete
d5bf546564f6: Pull complete
Digest: sha256:fa23b996c951b5fcfa569dff1cae870fc5144c8f9c4fb3a0914a8fc180039418
Status: Downloaded newer image for docker.io/mysql:5.6
0370dd8adfc4c91be3b22819eacf82029dfd3426ab024d2ca33098916f21be6f

╭─jivanov@logrhythm01  ~
╰─$ sudo docker run -ti --name mediawiki --link mediawiki-mysql:mysql -v /data/mediawiki:/data:rw -e MEDIAWIKI_SITE_SERVER=http://<snip>:8001 -e MEDIAWIKI_SITE_NAME=<snip> -e MEDIAWIKI_DB_USER=<snip> -e MEDIAWIKI_DB_PASSWORD=<snip> -e MEDIAWIKI_UPDATE=true wikimedia/mediawiki
PHP Notice:  Undefined index: MEDIAWIKI_DB_TYPE in - on line 4
info: Running maintenance/update.php
MediaWiki 1.27.0-wmf.9 Updater

Your composer.lock file is up to date with current dependencies!
Going to run database updates for mediawiki
Depending on the size of your database this may take a while!
Turning off Content Handler DB fields for this part of upgrade.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards.
...have rc_type field in recentchanges table.
...index new_name_timestamp already set on recentchanges table.
...have user_real_name field in user table.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...have pagelinks; skipping old links table updates
...il_from OK
...have rc_ip field in recentchanges table.
...index PRIMARY already set on image table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...logging table already exists.
...have user_token field in user table.
...have wl_notificationtimestamp field in watchlist table.
...watchlist talk page rows already present.
...user table does not contain user_emailauthenticationtimestamp field.
...page table already exists.
...have log_params field in logging table.
...logging table has correct log_title encoding.
...have ar_rev_id field in archive table.
...have page_len field in page table.
...revision table does not contain inverse_timestamp field.
...have rev_text_id field in revision table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have user_email_token field in user table.
...have ar_text_id field in archive table.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...have img_media_type field in image table.
...already have pagelinks table.
...image table does not contain img_type field.
...already have unique user_name index.
...user_groups table exists and is in current format.
...have ss_total_pages field in site_stats table.
...user_newtalk table already exists.
...transcache table already exists.
...have iw_trans field in interwiki table.
...wl_notificationtimestamp is already nullable.
...index times already set on logging table.
...have ipb_range_start field in ipblocks table.
...no page_random rows needed to be set
...have user_registration field in user table.
...templatelinks table already exists
...externallinks table already exists.
...job table already exists.
...have ss_images field in site_stats table.
...langlinks table already exists.
...querycache_info table already exists.
...filearchive table already exists.
...have ipb_anon_only field in ipblocks table.
...index rc_ns_usertext already set on recentchanges table.
...index rc_user_text already set on recentchanges table.
...have user_newpass_time field in user table.
...redirect table already exists.
...querycachetwo table already exists.
...have ipb_enable_autoblock field in ipblocks table.
...index pl_namespace on table pagelinks includes field pl_from.
...index tl_namespace on table templatelinks includes field tl_from.
...index il_to on table imagelinks includes field il_from.
...have rc_old_len field in recentchanges table.
...have user_editcount field in user table.
...page_restrictions table already exists.
...have log_id field in logging table.
...have rev_parent_id field in revision table.
...have pr_id field in page_restrictions table.
...have rev_len field in revision table.
...have rc_deleted field in recentchanges table.
...have log_deleted field in logging table.
...have ar_deleted field in archive table.
...have ipb_deleted field in ipblocks table.
...have fa_deleted field in filearchive table.
...have ar_len field in archive table.
...have ipb_block_email field in ipblocks table.
...index cl_sortkey on table categorylinks includes field cl_from.
...have oi_metadata field in oldimage table.
...index usertext_timestamp already set on archive table.
...index img_usertext_timestamp already set on image table.
...index oi_usertext_timestamp already set on oldimage table.
...have ar_page_id field in archive table.
...have img_sha1 field in image table.
...protected_titles table already exists.
...have ipb_by_text field in ipblocks table.
...page_props table already exists.
...updatelog table already exists.
...category table already exists.
...category table already populated.
...have ar_parent_id field in archive table.
...have user_last_timestamp field in user_newtalk table.
...protected_titles table has correct pt_title encoding.
...have ss_active_users field in site_stats table.
...ss_active_users user count set...
...have ipb_allow_usertalk field in ipblocks table.
...pl_namespace, tl_namespace, il_to indices are already UNIQUE.
...change_tag table already exists.
...tag_summary table already exists.
...valid_tag table already exists.
...user_properties table already exists.
...log_search table already exists.
...have log_user_text field in logging table.
...l10n_cache table already exists.
...index ls_field_val already set on log_search table.
...index change_tag_rc_tag already set on change_tag table.
...have rd_interwiki field in redirect table.
...transcache tc_time already converted.
...*_mime_minor fields are already long enough.
...iwlinks table already exists.
...index iwl_prefix_title_from already set on iwlinks table.
...have ul_value field in updatelog table.
...have iw_api field in interwiki table.
...iwl_prefix key doesn't exist.
...have cl_collation field in categorylinks table.
...categorylinks up-to-date.
...collations up-to-date.
...module_deps table already exists.
...ar_page_revid key doesn't exist.
...index ar_revid already set on archive table.
...ll_lang is up-to-date.
...user_last_timestamp is already nullable.
...index user_email already set on user table.
...up_property in table user_properties already modified by patch patch-up_property.sql.
...uploadstash table already exists.
...user_former_groups table already exists.
...index type_action already set on logging table.
...have rev_sha1 field in revision table.
...batch conversion of user_options: nothing to migrate. done.
...user table does not contain user_options field.
...have ar_sha1 field in archive table.
...index page_redirect_namespace_len already set on page table.
...have us_chunk_inx field in uploadstash table.
...have job_timestamp field in job table.
...index page_user_timestamp already set on revision table.
...have ipb_parent_block_id field in ipblocks table.
...index ipb_parent_block_id already set on ipblocks table.
...category table does not contain cat_hidden field.
...have rev_content_format field in revision table.
...have rev_content_model field in revision table.
...have ar_content_format field in archive table.
...have ar_content_model field in archive table.
...have page_content_model field in page table.
Content Handler DB fields should be usable now.
...site_stats table does not contain ss_admins field.
...recentchanges table does not contain rc_moved_to_title field.
...sites table already exists.
...have fa_sha1 field in filearchive table.
...have job_token field in job table.
...have job_attempts field in job table.
...have us_props field in uploadstash table.
...ug_group in table user_groups already modified by patch patch-ug_group-length-increase-255.sql.
...ufg_group in table user_former_groups already modified by patch patch-ufg_group-length-increase-255.sql.
...index pp_propname_page already set on page_props table.
...index img_media_mime already set on image table.
...iwl_prefix_title_from index is already non-UNIQUE.
...index iwl_prefix_from_title already set on iwlinks table.
...have ar_id field in archive table.
...have el_id field in externallinks table.
...have rc_source field in recentchanges table.
...index log_user_text_type_time already set on logging table.
...index log_user_text_time already set on logging table.
...have page_links_updated field in page table.
...have user_password_expires field in user table.
...have pp_sortkey field in page_props table.
...recentchanges table does not contain rc_cur_time field.
...index wl_user_notificationtimestamp already set on watchlist table.
...have page_lang field in page table.
...have pl_from_namespace field in pagelinks table.
...have tl_from_namespace field in templatelinks table.
...have il_from_namespace field in imagelinks table.
...img_major_mime in table image already modified by patch patch-img_major_mime-chemical.sql.
...oi_major_mime in table oldimage already modified by patch patch-oi_major_mime-chemical.sql.
...fa_major_mime in table filearchive already modified by patch patch-fa_major_mime-chemical.sql.
...user_id is already unsigned int.
...rc_comment in table recentchanges already modified by patch patch-editsummary-length.sql.
...hitcounter doesn't exist.
...site_stats table does not contain ss_total_views field.
...page table does not contain page_counter field.
...msg_resource_links doesn't exist.
...msg_resource doesn't exist.
...site_stats is populated...done.
...Update 'populate rev_len and ar_len' already logged as completed.
...Update 'populate rev_sha1' already logged as completed.
...img_sha1 column of image table already populated.
...protocol-relative URLs in externallinks table already fixed.
...fa_sha1 column of filearchive table already populated.
...*_from_namespace column of backlink tables already populated.
...Update 'FixDefaultJsonContentPages' already logged as completed.
Purging caches...done.

Done in 0.2 s.
[Thu Oct 20 19:35:05.208010 2016] [core:warn] [pid 23] AH00111: Config variable ${MEDIAWIKI_RESTBASE_URL} is not defined
AH00526: Syntax error on line 23 of /etc/apache2/mediawiki.conf:
ProxyPass URL must be absolute!: ${MEDIAWIKI_RESTBASE_URL}/
Action '-e info -D FOREGROUND' failed.
The Apache error log may have more information.

PHP Notice: Undefined index: MEDIAWIKI_DB_TYPE in - on line 4 caught my eye but that aforementioned documentation says -e MEDIAWIKI_DB_TYPE=... (defaults to mysql, but can also be postgres) which is apparently a false truth and should be remedied in the documentation.

After adding -e MEDIAWIKI_DB_TYPE=mysql, I didn't see a reference to MEDIAWIKI_DB_TYPE which is a good thing but the end result is still exactly the same.

This is disappointing.

I just took a look at https://github.com/wikimedia/mediawiki-containers and it seemed to install seemlessly!
It seems like great work has been happening here since I last tried this out!

1 this that happened was after the install had finished running install / update.php the script hung / didnt close gracefully, I had to kill it. But everything seems to be correctly installed

Currently, the docker images themselves are not yet very flexible, and not really optimized for a stand-alone install. I created them for use with https://github.com/wikimedia/mediawiki-containers, which is a quick prototype.

We now have several efforts at WMF converge towards containers, and we are discussing generalizing these images for use in development, CI, mediawiki-containers, and (eventually) production. Sharing the same containers should make it a lot more feasible to provide a well-tested & maintained container based distribution solution.

Looking at https://github.com/wikimedia/mediawiki-docker, I cannot get a container to run.

[Thu Oct 20 19:35:05.208010 2016] [core:warn] [pid 23] AH00111: Config variable ${MEDIAWIKI_RESTBASE_URL} is not defined
AH00526: Syntax error on line 23 of /etc/apache2/mediawiki.conf:
ProxyPass URL must be absolute!: ${MEDIAWIKI_RESTBASE_URL}/

I see no mention of MEDIAWIKI_RESTBASE_URL anywhere in there.

This is T151051: Apache in mediawiki-docker(wikimedia/mediawiki) crashes because the Apache was complaining about MEDIAWIKI_RESTBASE_URL, which has had a patch available for a month.
@GWicke , could you review those pull requests?

PHP Notice: Undefined index: MEDIAWIKI_DB_TYPE in - on line 4 caught my eye but that aforementioned documentation says -e MEDIAWIKI_DB_TYPE=... (defaults to mysql, but can also be postgres) which is apparently a false truth and should be remedied in the documentation.

After adding -e MEDIAWIKI_DB_TYPE=mysql, I didn't see a reference to MEDIAWIKI_DB_TYPE which is a good thing but the end result is still exactly the same.

Could you create another task about that?

I think this is a great initiative and wish I'd noticed it earlier.

I've spent a few years deploying MW and find that for a basic install it is quite easy. Once you start adding VE and Parsoid and Mathoid and Graphoid and Elasticsearch and so on to get a modern platform it all becomes very much more challenging. Mostly due to lack of "package deals" and installation instructions being atomically related to packages/extensions/skins with little guidance of how to put things together (MW+parsoid+restbase+mathoid etc.).

The support for deploying a fully-featured platform from a documentation point of view is fairly absent and very piecemeal and I gather that's partly because it's not what is required for wikimedia deploys however I think many people and organisations would significantly benefit from having a fully-featured wiki deployable within 10-15 minutes using container technology which is fairly easy to use (and Docker is).

Is there any interest in receiving PRs against the Github repo for:

  1. implementing this via Docker Swarm
  2. deploying via Git to bring through extensions?
  3. deploying extensions and skins using Git (i.e. no Composer or minimal composer). Composer once seemed to have promise but whether it is the supported, preferred method is no longer obvious to me (wouldn't mind a steer on this).
  4. adding Semantic Mediawiki
  5. adding support for Certbot/Let's Encrypt
  6. adding containers for CirrusSearch/Elasticsearch, Graphoid, Mathoid
  7. providing some kind of integration with either AWS or GCE for ready installs by third parties
  8. providing daily backups created and able to be put on a separate volume, perhaps with a script for a little rsyncing.

I'd like to work on this, although I am somewhat limited by ability and time. My MW installation is becoming fragile and brittle and out-of-date and this seems like the best way forward at present. I'd target supporting MW 1.28 initially.

  1. deploying extensions and skins using Git (i.e. no Composer or minimal composer). Composer once seemed to have promise but whether it is the supported, preferred method is no longer obvious to me (wouldn't mind a steer on this).

Installing Extensions via Composer is not considered to be a best practice by the general MediaWiki developer community. See T467: RfC: Extension management with Composer for slightly more detail. Git clones or tarballs would be the recommended method.

I've done a lot of work with this. I've even done rudimentary swarm deployments and some work with restbase:

https://github.com/rlewkowicz/docker-mediawiki-stack/tree/REL1_28

I like to think the whole setup is pretty solid. It's managed with Jenkins and should stay pretty up todate. My Jenkins jobs need some love, but I'm really happy with the work I've done so far.

There's plenty of rough edges. I distribute with composer deps pre installed. The purist probably would have a heart attack, but the goal is the end user experience. For the most part it should just be "Wow this just works".

Thanks @Ryan.lewkowicz this looks like a great piece of work. I have separately been creating quite a complex docker system to orchestrate containers. I'm very interested in having a look at your work.

Installing Extensions via Composer is not considered to be a best practice by the general MediaWiki developer community. See T467: RfC: Extension management with Composer for slightly more detail. Git clones or tarballs would be the recommended method.

My understanding of T467: RfC: Extension management with Composer is that this:

Composer can and should be used to pull in any dependencies an extension may have, and it may also be used to install the code of an extension, and to auto-load an extension's classes. It shall not be used to activate the extension - for that, the wfLoadExtensions should be used.

is the current majority opinion on the subject.

Hello, What is the status of this project?

...

  1. adding containers for CirrusSearch/Elasticsearch, Graphoid, Mathoid

Is there any progress on a CirrusSearch container?

@GWicke I'm keen to push forward with this effort, as my development environment is now run by docker.
Having a flexible mediawiki image is something that would be beneficial and probably something that I could slowly work on over time.

Has any through be put into moving these repos to gerrit?

Hello @Addshore ! We are working on getting a basic development environment set up using Minikube. Take a look at the mediawiki-containers repository, specifically the instructions on how to set it up. We are in the process of developing a tool that will allow you to easily set up and manipulate your dev environment for a specific service (later on, we plan to expand it to be able to do the same for MediaWiki itself as well as its extensions). There is a lot to do there and we would certainly appreciate any help! Let us know if you are interested in helping out.

@mobrovac to me it generally seems like the effort there has skipped a few stages. In my mind the first goal should be vanilla mediawiki container that is build and published on every commit, or at least on every branch automatically.
Also gwicke/docker-mediawiki IMO seems to currently do stuff in a pretty odd way (does many things in the docker-entrypoint)

I'm definitely keen to help out and get stuck in. Is there currently any sort of list of targets / roadmap for this whole thing?

In Fact, coming back to this task and reading point 1 in the list I really think this effort has missed the "a vanilla MediaWiki" stage

GWicke edited projects, added Services (doing); removed Services.

Take a look at my solution, maybe you'll find there something useful.
https://github.com/pastakhov/compose-mediawiki-ubuntu

I created an issue for Docker Library. Perhaps they'll be able to help us out with this. :)

I created a very basic mediawiki image:
https://hub.docker.com/r/davidbarratt/mediawiki/

I'm hoping that the docker library can contain something like this and then wikimedia/mediawiki can extend the basic one in docker library with more advanced features.

@dbarratt where is the code for said image?
I dont see it linked above or on docker or git hub!

I was going to create a default LocalSettings.php file that used environment variables and would be copied into the container (so you could just update the environment variables). But because of T172555: If LocalSettings.php exists, but database is empty, user should be prompted to install and not download new LocalSettings.php that seemed pointless.

Just an update on this, deciding on where (org) the repo should be hosted and if Docker should co-maintain:
https://github.com/docker-library/official-images/issues/3271#issuecomment-321017249

Docker would prefer for the docker code to be in the wikimedia org on GitHub:
https://github.com/docker-library/official-images/issues/3271#issuecomment-321698260

I think this is fine, but I think we should takeover the existing repo found here:
https://github.com/wikimedia/mediawiki-docker

I talked to @Addshore about this and he agrees, unless someone else has another idea for a name, the existing repo would be archived under a different name.

Also seeking a response from @mobrovac (the existing maintainer) before blowing out the existing repo, but I have not received any response from him.

BOOM!
https://hub.docker.com/_/mediawiki/

This is obviously not meant to solve everyone's problems. But should be considered a "base" for you to extend from.

Woohoo, congrats :) Do you think you could fill out the docker section on https://www.mediawiki.org/wiki/Comparison_of_distribution_options ?

Done. But @Addshore should probably take a look as well. :)

The image is using Mediawiki version 1.29.0, but the latest version is 1.29.1.

I do not know you internal process when you release a new version, but the docker version should be updated the same time you do a release.

The image is using Mediawiki version 1.29.0, but the latest version is 1.29.1.

https://github.com/wikimedia/mediawiki-docker/pull/36

@GWicke The image https://hub.docker.com/r/wikimedia/mediawiki/ is under wikimedia account (hence looks official) but the description is misleading as it says "This image tracks latest production" though it was last updated 4 years ago.

@SD0001: Hi, deactivated accounts won't answer; plus this task is about creating a package which happened. Please file new tasks for new issues - thanks a lot! :)