You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "Help:Development recommendations for easily moving to production"

From Wikitech-static
Jump to navigation Jump to search
imported>SRodlund
imported>SRodlund
Line 1: Line 1:
{{note|content= Please help improve the content of this page: https://phabricator.wikimedia.org/T233659}}
+
{{Toolforge nav}}
 +
 
 +
== Overview ==
 +
 
 +
This page describes processes for advanced users, specifically individuals who are developing services aimed at Wikimedia production.
  
 
== Avoid pip, pecl, gems, and other language specific repositories ==
 
== Avoid pip, pecl, gems, and other language specific repositories ==
  
Please, take care when using language specific repositories, like pip, pecl, etc. The operations team avoids these like the plague because it generally involves far much more work in the long run.
+
Please, take care when using language specific repositories, like pip, pecl, etc. The operations team avoids these because they generally involve far much more work in the long run.In production we do not use third party repositories because we don't trust them.
 +
 
 +
 
 +
'''When pushing to production, all dependencies must:'''
 +
 
 +
* Be installable as Debian packages
 +
* From the Ubuntu repository
 +
 
 +
If a package isn't available in the Ubuntu repository it gets packaged and stuck into our custom repository.
  
In production we do not use third party repositories since we don't trust them. When we push something to production, all dependencies must be installable as debian packages, and preferably from the Ubuntu repository. If a package isn't available in the Ubuntu repository it gets packaged and stuck into our custom repository.
+
=== Language specific repositories ===
  
When using language specific repositories, it may install newer versions of libraries than available in the Ubuntu repository. Your application may then depend on the newer versions, and when we puppetize the system, the newer versions have to be backported to whichever distro version we are using.
+
When using language specific repositories, newer versions of libraries than are available in the Ubuntu repository may be installed. Your application may then depend on the newer versions, and when we puppetize the system, the newer versions have to be backported to whichever distro version we are using.
  
We recommend that before using a language specific repository, that you check to see if the required library exists in the Ubuntu repository first. Unless the packaged version is too old, please use it rather than the version in the language specific repository. When using a language specific repository, please document the library that was installed, so that it can be packaged when the service is to be puppetized and deployed to production.
+
We recommend that before using a language specific repository, you check to see if the required library exists in the Ubuntu repository first. Unless the packaged version is too old, please use it rather than the version in the language specific repository. When using a language specific repository, please document the library that was installed, so that it can be packaged when the service is puppetized and deployed to production.
  
 
== Document all package installations, all modified configuration files, and any commands run to configure a service ==
 
== Document all package installations, all modified configuration files, and any commands run to configure a service ==
Line 18: Line 30:
  
 
It's important to know which ports and protocols are in use by your service, and how that affects the security of a service. Memcache, for instance, runs on 11211, and by default has no security. It's important to firewall the service, or to ensure it isn't accessible to the public. Many services have considerations like this, and documenting these makes them much easier to puppetize.
 
It's important to know which ports and protocols are in use by your service, and how that affects the security of a service. Memcache, for instance, runs on 11211, and by default has no security. It's important to firewall the service, or to ensure it isn't accessible to the public. Many services have considerations like this, and documenting these makes them much easier to puppetize.
 +
 +
{{:Help:Cloud Services communication}}
 +
  
 
[[Category:Cloud VPS]]
 
[[Category:Cloud VPS]]
 +
[[Category:Documentation]]
 +
[[Category:Cloud Services]]

Revision as of 23:52, 15 January 2020

Overview

This page describes processes for advanced users, specifically individuals who are developing services aimed at Wikimedia production.

Avoid pip, pecl, gems, and other language specific repositories

Please, take care when using language specific repositories, like pip, pecl, etc. The operations team avoids these because they generally involve far much more work in the long run.In production we do not use third party repositories because we don't trust them.


When pushing to production, all dependencies must:

  • Be installable as Debian packages
  • From the Ubuntu repository

If a package isn't available in the Ubuntu repository it gets packaged and stuck into our custom repository.

Language specific repositories

When using language specific repositories, newer versions of libraries than are available in the Ubuntu repository may be installed. Your application may then depend on the newer versions, and when we puppetize the system, the newer versions have to be backported to whichever distro version we are using.

We recommend that before using a language specific repository, you check to see if the required library exists in the Ubuntu repository first. Unless the packaged version is too old, please use it rather than the version in the language specific repository. When using a language specific repository, please document the library that was installed, so that it can be packaged when the service is puppetized and deployed to production.

Document all package installations, all modified configuration files, and any commands run to configure a service

Documenting how a service is installed and configured makes the puppetization of a service much easier. It should be possible to fully puppetize a system just by reading the documentation. This also means that when a service is changed after being deployed to production that its documentation should be updated as well.

Know and document any ports and protocols in use by your service

It's important to know which ports and protocols are in use by your service, and how that affects the security of a service. Memcache, for instance, runs on 11211, and by default has no security. It's important to firewall the service, or to ensure it isn't accessible to the public. Many services have considerations like this, and documenting these makes them much easier to puppetize.

Communication and support

We communicate and provide support through several primary channels. Please reach out with questions and to join the conversation.

Communicate with us
Connect Best for
Phabricator Workboard #Cloud-Services Task tracking and bug reporting
IRC Channel #wikimedia-cloud connect General discussion and support
Mailing List cloud@ Information about ongoing initiatives, general discussion and support
Announcement emails cloud-announce@ Information about critical changes (all messages mirrored to cloud@)
News wiki page News Information about major near-term plans
Cloud Services Blog Clouds & Unicorns Learning more details about some of our work
Wikimedia Technology Blog techblog.wikimedia.org News and stories from the Wikimedia technical movement