project: remove obviously outdated docs
Remove the following files: - ARM.md (ARM hosts including ARM64 are fully supported now) - IRC-ADMINISTRATION.md (IRC has gone) - PACKAGE-REPO-MAINTENANCE.md (deb/rpm has moved to https://github.com/docker/docker-ce-packaging) - TOOLS.md (most tools except Jenkins are unused/unmaintained) Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This commit is contained in:
Akihiro Suda
parent
4609153995
commit
a8ae48d94f
4 changed files with 0 additions and 219 deletions
|
|
@ -1,45 +0,0 @@
|
|||
# ARM support
|
||||
|
||||
The ARM support should be considered experimental. It will be extended step by step in the coming weeks.
|
||||
|
||||
Building a Docker Development Image works in the same fashion as for Intel platform (x86-64).
|
||||
Currently we have initial support for 32bit ARMv7 devices.
|
||||
|
||||
To work with the Docker Development Image you have to clone the Docker/Docker repo on a supported device.
|
||||
It needs to have a Docker Engine installed to build the Docker Development Image.
|
||||
|
||||
From the root of the Docker/Docker repo one can use make to execute the following make targets:
|
||||
- make validate
|
||||
- make binary
|
||||
- make build
|
||||
- make deb
|
||||
- make bundles
|
||||
- make default
|
||||
- make shell
|
||||
- make test-unit
|
||||
- make test-integration
|
||||
- make
|
||||
|
||||
The Makefile does include logic to determine on which OS and architecture the Docker Development Image is built.
|
||||
Based on OS and architecture it chooses the correct Dockerfile.
|
||||
For the ARM 32bit architecture it uses `Dockerfile.armhf`.
|
||||
|
||||
So for example in order to build a Docker binary one has to:
|
||||
1. clone the Docker/Docker repository on an ARM device `git clone https://github.com/docker/docker.git`
|
||||
2. change into the checked out repository with `cd docker`
|
||||
3. execute `make binary` to create a Docker Engine binary for ARM
|
||||
|
||||
## Kernel modules
|
||||
A few libnetwork integration tests require that the kernel be
|
||||
configured with "dummy" network interface and has the module
|
||||
loaded. However, the dummy module may be not loaded automatically.
|
||||
|
||||
To load the kernel module permanently, run these commands as `root`.
|
||||
|
||||
modprobe dummy
|
||||
echo "dummy" >> /etc/modules
|
||||
|
||||
On some systems you also have to sync your kernel modules.
|
||||
|
||||
oc-sync-kernel-modules
|
||||
depmod
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Freenode IRC Administration Guidelines and Tips
|
||||
|
||||
This is not meant to be a general "Here's how to IRC" document, so if you're
|
||||
looking for that, check Google instead. ♥
|
||||
|
||||
If you've been charged with helping maintain one of Docker's now many IRC
|
||||
channels, this might turn out to be useful. If there's information that you
|
||||
wish you'd known about how a particular channel is organized, you should add
|
||||
deets here! :)
|
||||
|
||||
## `ChanServ`
|
||||
|
||||
Most channel maintenance happens by talking to Freenode's `ChanServ` bot. For
|
||||
example, `/msg ChanServ ACCESS <channel> LIST` will show you a list of everyone
|
||||
with "access" privileges for a particular channel.
|
||||
|
||||
A similar command is used to give someone a particular access level. For
|
||||
example, to add a new maintainer to the `#docker-maintainers` access list so
|
||||
that they can contribute to the discussions (after they've been merged
|
||||
appropriately in a `MAINTAINERS` file, of course), one would use `/msg ChanServ
|
||||
ACCESS #docker-maintainers ADD <nick> maintainer`.
|
||||
|
||||
To setup a new channel with a similar `maintainer` access template, use a
|
||||
command like `/msg ChanServ TEMPLATE <channel> maintainer +AV` (`+A` for letting
|
||||
them view the `ACCESS LIST`, `+V` for auto-voice; see `/msg ChanServ HELP FLAGS`
|
||||
for more details).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
The most common cause of not-getting-auto-`+v` woes is people not being
|
||||
`IDENTIFY`ed with `NickServ` (or their current nickname not being `GROUP`ed with
|
||||
their main nickname) -- often manifested by `ChanServ` responding to an `ACCESS
|
||||
ADD` request with something like `xyz is not registered.`.
|
||||
|
||||
This is easily fixed by doing `/msg NickServ IDENTIFY OldNick SecretPassword`
|
||||
followed by `/msg NickServ GROUP` to group the two nicknames together. See
|
||||
`/msg NickServ HELP GROUP` for more information.
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
# Apt & Yum Repository Maintenance
|
||||
## A maintainer's guide to managing Docker's package repos
|
||||
|
||||
### How to clean up old experimental debs and rpms
|
||||
|
||||
We release debs and rpms for experimental nightly, so these can build up.
|
||||
To remove old experimental debs and rpms, and _ONLY_ keep the latest, follow the
|
||||
steps below.
|
||||
|
||||
1. Checkout docker master
|
||||
|
||||
2. Run clean scripts
|
||||
|
||||
```bash
|
||||
docker build --rm --force-rm -t docker-dev:master .
|
||||
docker run --rm -it --privileged \
|
||||
-v /path/to/your/repos/dir:/volumes/repos \
|
||||
-v $HOME/.gnupg:/root/.gnupg \
|
||||
-e GPG_PASSPHRASE \
|
||||
-e DOCKER_RELEASE_DIR=/volumes/repos \
|
||||
docker-dev:master hack/make.sh clean-apt-repo clean-yum-repo generate-index-listing sign-repos
|
||||
```
|
||||
|
||||
3. Upload the changed repos to `s3` (if you host on s3)
|
||||
|
||||
4. Purge the cache, PURGE the cache, PURGE THE CACHE!
|
||||
|
||||
### How to get out of a sticky situation
|
||||
|
||||
Sh\*t happens. We know. Below are steps to get out of any "hash-sum mismatch" or
|
||||
"gpg sig error" or the likes error that might happen to the apt repo.
|
||||
|
||||
**NOTE:** These are apt repo specific, have had no experience with anything similar
|
||||
happening to the yum repo in the past so you can rest easy.
|
||||
|
||||
For each step listed below, move on to the next if the previous didn't work.
|
||||
Otherwise CELEBRATE!
|
||||
|
||||
1. Purge the cache.
|
||||
|
||||
2. Did you remember to sign the debs after releasing?
|
||||
|
||||
Re-sign the repo with your gpg key:
|
||||
|
||||
```bash
|
||||
docker build --rm --force-rm -t docker-dev:master .
|
||||
docker run --rm -it --privileged \
|
||||
-v /path/to/your/repos/dir:/volumes/repos \
|
||||
-v $HOME/.gnupg:/root/.gnupg \
|
||||
-e GPG_PASSPHRASE \
|
||||
-e DOCKER_RELEASE_DIR=/volumes/repos \
|
||||
docker-dev:master hack/make.sh sign-repos
|
||||
```
|
||||
|
||||
Upload the changed repo to `s3` (if that is where you host)
|
||||
|
||||
PURGE THE CACHE.
|
||||
|
||||
3. Run Jess' magical, save all, only in case of extreme emergencies, "you are
|
||||
going to have to break this glass to get it" script.
|
||||
|
||||
```bash
|
||||
docker build --rm --force-rm -t docker-dev:master .
|
||||
docker run --rm -it --privileged \
|
||||
-v /path/to/your/repos/dir:/volumes/repos \
|
||||
-v $HOME/.gnupg:/root/.gnupg \
|
||||
-e GPG_PASSPHRASE \
|
||||
-e DOCKER_RELEASE_DIR=/volumes/repos \
|
||||
docker-dev:master hack/make.sh update-apt-repo generate-index-listing sign-repos
|
||||
```
|
||||
|
||||
4. Upload the changed repo to `s3` (if that is where you host)
|
||||
|
||||
PURGE THE CACHE.
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
# Tools
|
||||
|
||||
This page describes the tools we use and infrastructure that is in place for
|
||||
the Docker project.
|
||||
|
||||
### CI
|
||||
|
||||
The Docker project uses [Jenkins](https://jenkins.dockerproject.org/) as our
|
||||
continuous integration server. Each Pull Request to Docker is tested by running the
|
||||
equivalent of `make all`. We chose Jenkins because we can host it ourselves and
|
||||
we run Docker in Docker to test.
|
||||
|
||||
#### Leeroy
|
||||
|
||||
Leeroy is a Go application which integrates Jenkins with
|
||||
GitHub pull requests. Leeroy uses
|
||||
[GitHub hooks](https://developer.github.com/v3/repos/hooks/)
|
||||
to listen for pull request notifications and starts jobs on your Jenkins
|
||||
server. Using the Jenkins
|
||||
[notification plugin](https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin),
|
||||
Leeroy updates the pull request using GitHub's
|
||||
[status API](https://developer.github.com/v3/repos/statuses/)
|
||||
with pending, success, failure, or error statuses.
|
||||
|
||||
The leeroy repository is maintained at
|
||||
[github.com/docker/leeroy](https://github.com/docker/leeroy).
|
||||
|
||||
#### GordonTheTurtle IRC Bot
|
||||
|
||||
The GordonTheTurtle IRC Bot lives in the
|
||||
[#docker-maintainers](https://botbot.me/freenode/docker-maintainers/) channel
|
||||
on Freenode. He is built in Go and is based off the project at
|
||||
[github.com/fabioxgn/go-bot](https://github.com/fabioxgn/go-bot).
|
||||
|
||||
His main command is `!rebuild`, which rebuilds a given Pull Request for a repository.
|
||||
This command works by integrating with Leroy. He has a few other commands too, such
|
||||
as `!gif` or `!godoc`, but we are always looking for more fun commands to add.
|
||||
|
||||
The gordon-bot repository is maintained at
|
||||
[github.com/docker/gordon-bot](https://github.com/docker/gordon-bot)
|
||||
|
||||
### NSQ
|
||||
|
||||
We use [NSQ](https://github.com/bitly/nsq) for various aspects of the project
|
||||
infrastructure.
|
||||
|
||||
#### Hooks
|
||||
|
||||
The hooks project,
|
||||
[github.com/crosbymichael/hooks](https://github.com/crosbymichael/hooks),
|
||||
is a small Go application that manages web hooks from github, hub.docker.com, or
|
||||
other third party services.
|
||||
|
||||
It can be used for listening to github webhooks & pushing them to a queue,
|
||||
archiving hooks to rethinkdb for processing, and broadcasting hooks to various
|
||||
jobs.
|
||||
|
||||
#### Docker Master Binaries
|
||||
|
||||
One of the things queued from the Hooks are the building of the Master
|
||||
Binaries. This happens on every push to the master branch of Docker. The
|
||||
repository for this is maintained at
|
||||
[github.com/docker/docker-bb](https://github.com/docker/docker-bb).
|
||||
Loading…
Reference in a new issue