mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
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…
Add table
Add a link
Reference in a new issue