Browse Source

extra detail about logs, docker, etc.

master
Brennen Bearnes 2 years ago
parent
commit
d46c4631a1
1 changed files with 63 additions and 30 deletions
  1. +63
    -30
      index.md

+ 63
- 30
index.md View File

@ -1,6 +1,6 @@
# Zuul v3 Proof of Concept
Brennen Bearnes <bbearnes@wikimedia.org>, August 2019
Brennen Bearnes <bbearnes@wikimedia.org>, Fall 2019
## Summary
@ -36,18 +36,19 @@ Uncertain:
- I still don't know what the K8s story is like
- How do we implement the equivalent of pipelinelib?
- Will upstream make major architectural changes again?
In conclusion: It's imperfect and I'm not sure I _like_ Zuul, exactly, but I
at least narrowly/weakly believe that Zuul v3 would be our most effective
near-term choice for migration, whether as a temporary solution to be
supplanted by Argo in the fullness of time or as something more permanent.
In conclusion: It's imperfect and I'm not sure I _like_ it, but I
narrowly/weakly think that Zuul v3 would be our most effective near-term choice
for a migration, whether as a temporary solution to be supplanted by Argo in
the fullness of time or as something more permanent.
## Configuration
I spun up Zuul on DigitalOcean droplets under my personal account. I initially
tried to get Zuul working from scratch, following [Zuul From Scratch][scratch]
on a Debian Buster system. This proved difficult. I encountered
incompatibilities with Java runtimes and various other dependencies.
tried to follow [Zuul From Scratch][scratch] on a Debian Buster system. This
proved difficult. I encountered incompatibilities with Java runtimes and
various other dependencies.
Eventually, I fell back to [the docker-compose quick start][quick], as
described in the [initial evaluation task, T218138][T218138], with the addition
@ -86,8 +87,8 @@ Gerrit.
`zuul-config` is listed under _config-projects_ in the tenant config in
`etc_zuul/main.yaml`, which means that it runs with elevated privileges.
Normal projects (such as blubber) and a sort of standard library of Ansible
jobs called `zuul-jobs` are listed under _untrusted-projects_:
Normal projects (such as Blubber) and a sort of standard library of Ansible
jobs called [`zuul-jobs`][zuul-jobs] are listed under _untrusted-projects_:
```yaml
- tenant:
@ -125,13 +126,14 @@ brennen@lostsnail-0:~/zuul-config$ tree
3 directories, 6 files
```
`playbooks` contain base Ansible playbooks which are inherited by all jobs.
`zuul-config/playbooks/` contains base Ansible playbooks which are inherited by
all jobs. These playbooks, in turn, apply roles defined in the zuul-jobs repo
mentioned above.
`zuul.d` contains the following:
`zuul-config/zuul.d/projects.yaml` contains project definitions. The first uses
a regex to match on all projects:
```
# Project definitions - the first uses a regex to match on all projects:
brennen@lostsnail-0:~/zuul-config/zuul.d$ cat projects.yaml
```yaml
- project:
name: ^.*$
check:
@ -149,9 +151,11 @@ brennen@lostsnail-0:~/zuul-config/zuul.d$ cat projects.yaml
- noop
```
```
# Job definitions:
brennen@lostsnail-0:~/zuul-config/zuul.d$ cat jobs.yaml
`zuul-config/zuul.d/jobs.yaml` contains job definitions, and specifies the
playbooks for setting up and tearing down SSH keys, copying the project's
source to a node, and stashing the job's logs.
```yaml
- job:
name: base
parent: null
@ -176,9 +180,9 @@ brennen@lostsnail-0:~/zuul-config/zuul.d$ cat jobs.yaml
label: debian-buster
```
```
# Check and gate pipelines:
brennen@lostsnail-0:~/zuul-config/zuul.d$ cat pipelines.yaml
`zuul-config/zuul.d/pipelines.yaml` defines check and gate pipelines:
```yaml
- pipeline:
name: check
description: |
@ -236,6 +240,18 @@ brennen@lostsnail-0:~/zuul-config/zuul.d$ cat pipelines.yaml
mysql:
```
### Job Logging
Logs are copied to a shared volume using the `upload-logs` role provided in
`zuul-jobs`, and served by an Apache container. `upload-logs` can also handle
SCPing logs to a remote host.
There's an `upload-logs-swift` role for use with [OpenStack's Swift object
store][swift], although I haven't tried using it.
Other log stores would probably be easy enough to support, just by replacing
`upload-logs` with an appropriate playbook.
### Nodepool
Nodepool's configuration in `etc_nodepool/nodepool.yaml` includes a list of
@ -251,7 +267,7 @@ providers:
- name: "167.71.188.58"
labels: debian-buster
host-key: "actual-host-key-goes-here"
# Probably commented out because I couldn't get it to work:
# Probably set to false because I couldn't get it to work:
host-key-checking: false
python-path: /usr/bin/python3
username: root
@ -263,11 +279,11 @@ Individual projects work essentially the same way `zuul-config` does: A
`.zuul.yaml` or a `.zuul.d/` is written to define jobs, which run Ansible
playbooks, and these jobs are added to pipelines for the project.
As I understand it, all of this configuration is shared between the projects in
a tenant - so a project can run playbooks from a different project, for
example.
As I understand it, _all_ of this configuration is shared between the projects
in a tenant - so a project can run playbooks defined in a different project,
for example.
Here's the `.zuul.yaml` I wrote for blubber:
Here's the `.zuul.yaml` I wrote for Blubber:
```
brennen@lostsnail-0:~/blubber$ cat .zuul.yaml
@ -293,7 +309,7 @@ brennen@lostsnail-0:~/blubber$ cat .zuul.yaml
This in turn references two playbooks:
```
brennen@lostsnail-0:~/blubber$ cat playbooks/blubber-build.yaml
brennen@lostsnail-0:~/blubber$ cat playbooks/blubber-build.yaml
- hosts: all
environment:
GOPATH=/root
@ -311,7 +327,7 @@ brennen@lostsnail-0:~/blubber$ cat playbooks/blubber-build.yaml
- make:
chdir: src/gerrit/blubber
brennen@lostsnail-0:~/blubber$ cat playbooks/blubber-test.yaml
brennen@lostsnail-0:~/blubber$ cat playbooks/blubber-test.yaml
- hosts: all
tasks:
- debug:
@ -330,9 +346,26 @@ our developers are already well familiar with.
We obviously don't want to run CI jobs as root on a continuously reused VM. In
principle, this is very solvable, but there is some work to be done.
[quick]: https://zuul-ci.org/docs/zuul/admin/quick-start.html
[scratch]: https://zuul-ci.org/docs/zuul/admin/zuul-from-scratch.html
It's probably worth noting that `zuul-jobs` includes roles for building and
uploading Docker images, described in the
[Docker Jobs](https://zuul-ci.org/docs/zuul-jobs/docker-jobs.html),
[Container Roles](https://zuul-ci.org/docs/zuul-jobs/container-roles.html), and
[Container Images](https://zuul-ci.org/docs/zuul-jobs/docker-image.html) sections
of the docs. That last one mentions this:
> The requires: docker-image attribute means that whenever this job (or any
> jobs which inherit from it) run, Zuul will search ahead of the change in the
> dependency graph to find any jobs which produce docker-images and tell this
> job about them. This allows the job to pull images from the intermediate
> registry into the buildset registry.
That sounds pretty neat, but like a lot of other things about Zuul it's
complicated and I don't quite understand it.
[T218138]: https://phabricator.wikimedia.org/T218138
[docker-compose]: https://opendev.org/zuul/zuul/src/branch/master/doc/source/admin/examples/docker-compose.yaml
[example-conf]: https://opendev.org/zuul/zuul/src/branch/master/doc/source/admin/examples/
[quick]: https://zuul-ci.org/docs/zuul/admin/quick-start.html
[scratch]: https://zuul-ci.org/docs/zuul/admin/zuul-from-scratch.html
[swift]: https://docs.openstack.org/swift/latest/
[zuul-jobs]: https://opendev.org/zuul/zuul-jobs

Loading…
Cancel
Save