mirror of
https://we.phorge.it/source/phorge.git
synced 2024-12-19 20:10:55 +01:00
Add a little Drydock documentation
Summary: Ref T9252. Provide some general descriptions of Drydock in the docs. Test Plan: Reading. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14215
This commit is contained in:
parent
4496176924
commit
c95fcb8970
1 changed files with 55 additions and 3 deletions
|
@ -1,8 +1,60 @@
|
||||||
@title Drydock User Guide
|
@title Drydock User Guide
|
||||||
@group userguide
|
@group userguide
|
||||||
|
|
||||||
Configuring Drydock for machine resource management.
|
Drydock, a software and hardware resource manager.
|
||||||
|
|
||||||
= Overview =
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
WARNING: Drydock is very new and has many sharp edges. Prepare yourself for
|
||||||
|
a challenging adventure in unmapped territory, not a streamlined experience
|
||||||
|
where things work properly or make sense.
|
||||||
|
|
||||||
|
Drydock is an infrastructure application that primarily helps other
|
||||||
|
applications coordinate during complex build and deployment tasks. Typically,
|
||||||
|
you will configure Drydock to enable capabilities in other applications:
|
||||||
|
|
||||||
|
- Harbormaster can use Drydock to host builds.
|
||||||
|
- In the future, Differential will be able to use Drydock to perform
|
||||||
|
server-side merges.
|
||||||
|
|
||||||
|
Users will not normally interact with Drydock directly.
|
||||||
|
|
||||||
|
|
||||||
|
What Drydock Does
|
||||||
|
=================
|
||||||
|
|
||||||
|
Drydock manages working copies, build hosts, and other software and hardware
|
||||||
|
resources that build and deployment processes may require in order to perform
|
||||||
|
useful work.
|
||||||
|
|
||||||
|
Many useful processes need a working copy of a repository (or some similar sort
|
||||||
|
of resource) so they can read files, perform version control operations, or
|
||||||
|
execute code.
|
||||||
|
|
||||||
|
For example, you might want to be able to automatically run unit tests, build a
|
||||||
|
binary, or generate documentation every time a new commit is pushed. Or you
|
||||||
|
might want to automatically merge a revision or cherry-pick a commit from a
|
||||||
|
development branch to a release branch. Any of these tasks need a working copy
|
||||||
|
of the repository before they can get underway.
|
||||||
|
|
||||||
|
These processes could just clone a new working copy when they started and
|
||||||
|
delete it when they finished. This works reasonably well at a small scale, but
|
||||||
|
will eventually hit limitations if you want to do things like: expand the build
|
||||||
|
tier to multiple machines; or automatically scale the tier up and down based on
|
||||||
|
usage; or reuse working copies to improve performance; or make sure things get
|
||||||
|
cleaned up after a process fails; or have jobs wait if the tier is too busy.
|
||||||
|
Solving these problems effectively requires coordination between the processes
|
||||||
|
doing the actual work.
|
||||||
|
|
||||||
|
Drydock solves these scaling problems by providing a central allocation
|
||||||
|
framework for //resources//, which are physical or virtual resources like a
|
||||||
|
build host or a working copy. Processes which need to share hardware or
|
||||||
|
software can use Drydock to coordinate creation, access, and destruction of
|
||||||
|
those resources.
|
||||||
|
|
||||||
|
Applications ask Drydock for resources matching a description, and it allocates
|
||||||
|
a corresponding resource by either finding a suitable unused resource or
|
||||||
|
creating a new resource. When work completes, the resource is returned to the
|
||||||
|
resource pool or destroyed.
|
||||||
|
|
||||||
NOTE: Drydock is extremely new and not very useful yet.
|
|
||||||
|
|
Loading…
Reference in a new issue