2019-01-31 13:44:04 -08:00
|
|
|
- name: Install packages
|
|
|
|
become: yes
|
|
|
|
package:
|
|
|
|
name:
|
|
|
|
- python-docker
|
|
|
|
- python-openssl
|
|
|
|
- python-passlib
|
|
|
|
- python-bcrypt
|
|
|
|
state: present
|
|
|
|
when: "'python3' not in ansible_python_interpreter"
|
|
|
|
- name: Install packages
|
|
|
|
become: yes
|
|
|
|
package:
|
|
|
|
name:
|
|
|
|
- python3-docker
|
|
|
|
- python3-openssl
|
|
|
|
- python3-passlib
|
|
|
|
- python3-bcrypt
|
|
|
|
state: present
|
|
|
|
when: "'python3' in ansible_python_interpreter"
|
|
|
|
- name: Ensure Docker registry volume directories exists
|
|
|
|
file:
|
|
|
|
state: directory
|
|
|
|
path: "{{ buildset_registry_root}}/{{ item }}"
|
|
|
|
loop:
|
|
|
|
- certs
|
|
|
|
- auth
|
|
|
|
# TODO: use password lookup after allowing access to it in Zuul
|
|
|
|
- name: Generate registry password
|
|
|
|
set_fact:
|
|
|
|
registry_password: "{{ (ansible_date_time.iso8601_micro | password_hash('sha256'))[-20:] }}"
|
|
|
|
- name: Write htpassword file
|
|
|
|
htpasswd:
|
|
|
|
create: true
|
|
|
|
crypt_scheme: bcrypt
|
|
|
|
path: "{{ buildset_registry_root}}/auth/htpasswd"
|
|
|
|
name: "zuul"
|
|
|
|
password: "{{ registry_password }}"
|
|
|
|
- name: Generate a TLS key for the Docker registry
|
|
|
|
openssl_privatekey:
|
|
|
|
path: "{{ buildset_registry_root}}/certs/domain.key"
|
|
|
|
- name: Generate a TLS CSR for the Docker registry
|
|
|
|
openssl_csr:
|
|
|
|
path: "{{ buildset_registry_root}}/certs/domain.csr"
|
|
|
|
privatekey_path: "{{ buildset_registry_root}}/certs/domain.key"
|
|
|
|
common_name: "{{ ansible_host }}"
|
2019-04-22 09:04:10 -07:00
|
|
|
subject_alt_name: "DNS:zuul-jobs.buildset-registry,DNS:{{ ansible_host }},IP:{{ ansible_host }},IP:127.0.0.1"
|
2019-01-31 13:44:04 -08:00
|
|
|
- name: Generate a TLS cert for the Docker registry
|
|
|
|
openssl_certificate:
|
|
|
|
path: "{{ buildset_registry_root}}/certs/domain.crt"
|
|
|
|
csr_path: "{{ buildset_registry_root}}/certs/domain.csr"
|
|
|
|
privatekey_path: "{{ buildset_registry_root}}/certs/domain.key"
|
|
|
|
provider: selfsigned
|
|
|
|
register: generated_cert
|
|
|
|
- name: Read TLS certificate
|
|
|
|
slurp:
|
|
|
|
src: "{{ generated_cert.filename }}"
|
|
|
|
register: certificate
|
|
|
|
- name: Decode TLS certificate
|
|
|
|
set_fact:
|
|
|
|
certificate: "{{ certificate.content | b64decode }}"
|
2019-03-01 15:52:01 -08:00
|
|
|
- name: Start a docker registry
|
2019-01-31 13:44:04 -08:00
|
|
|
docker_container:
|
2019-03-01 15:52:01 -08:00
|
|
|
name: buildset_registry
|
2019-01-31 13:44:04 -08:00
|
|
|
image: registry:2
|
|
|
|
state: started
|
|
|
|
restart_policy: always
|
|
|
|
ports:
|
|
|
|
- "5000:5000"
|
|
|
|
env:
|
|
|
|
REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
|
|
|
|
REGISTRY_HTTP_TLS_KEY: /certs/domain.key
|
|
|
|
REGISTRY_AUTH: htpasswd
|
|
|
|
REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
|
|
|
|
REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
|
|
|
|
volumes:
|
|
|
|
- "{{ buildset_registry_root}}/certs:/certs"
|
|
|
|
- "{{ buildset_registry_root}}/auth:/auth"
|
2019-03-01 15:52:01 -08:00
|
|
|
- name: Start a docker proxy
|
run-buildset-registry: run a dual registry
The docker registry daemon can either act as a private registry,
or as a pull-through proxy, but not both. Yet we need to be able
to serve private (speculative buildset) images as well as plain
upstream images. Our registry is used as a mirror and requires
authentication, therefore docker's normal behavior of falling back
on docker.io won't work because it will attempt to use our
credentials.
However, the registry daemon stores all of its state in the
filesystem, therefore we can run two instances of the registry
service, both pointing at the same data store. The first acts
as a pull-through proxy and will serve whatever files are already
in the local storage, or will fetch them from docker.io. The second
can be used to upload images into the local storage.
To make a long story short, whenever we push into the buildset
registry, we will use the second endpoint. Whenever the docker
daemon pulls from the buildset registry, it will use the first.
Change-Id: I296029068b5ef28ee56543741fe8c8deeefb5dfa
2019-02-21 13:49:49 -08:00
|
|
|
docker_container:
|
2019-03-01 15:52:01 -08:00
|
|
|
name: buildset_proxy
|
run-buildset-registry: run a dual registry
The docker registry daemon can either act as a private registry,
or as a pull-through proxy, but not both. Yet we need to be able
to serve private (speculative buildset) images as well as plain
upstream images. Our registry is used as a mirror and requires
authentication, therefore docker's normal behavior of falling back
on docker.io won't work because it will attempt to use our
credentials.
However, the registry daemon stores all of its state in the
filesystem, therefore we can run two instances of the registry
service, both pointing at the same data store. The first acts
as a pull-through proxy and will serve whatever files are already
in the local storage, or will fetch them from docker.io. The second
can be used to upload images into the local storage.
To make a long story short, whenever we push into the buildset
registry, we will use the second endpoint. Whenever the docker
daemon pulls from the buildset registry, it will use the first.
Change-Id: I296029068b5ef28ee56543741fe8c8deeefb5dfa
2019-02-21 13:49:49 -08:00
|
|
|
image: registry:2
|
|
|
|
state: started
|
|
|
|
restart_policy: always
|
|
|
|
ports:
|
|
|
|
- "5001:5000"
|
|
|
|
env:
|
|
|
|
REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
|
|
|
|
REGISTRY_HTTP_TLS_KEY: /certs/domain.key
|
|
|
|
REGISTRY_AUTH: htpasswd
|
|
|
|
REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
|
|
|
|
REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
|
2019-03-01 15:52:01 -08:00
|
|
|
REGISTRY_PROXY_REMOTEURL: https://registry-1.docker.io
|
|
|
|
REGISTRY_PROXY_USERNAME: ''
|
|
|
|
REGISTRY_PROXY_PASSWORD: ''
|
run-buildset-registry: run a dual registry
The docker registry daemon can either act as a private registry,
or as a pull-through proxy, but not both. Yet we need to be able
to serve private (speculative buildset) images as well as plain
upstream images. Our registry is used as a mirror and requires
authentication, therefore docker's normal behavior of falling back
on docker.io won't work because it will attempt to use our
credentials.
However, the registry daemon stores all of its state in the
filesystem, therefore we can run two instances of the registry
service, both pointing at the same data store. The first acts
as a pull-through proxy and will serve whatever files are already
in the local storage, or will fetch them from docker.io. The second
can be used to upload images into the local storage.
To make a long story short, whenever we push into the buildset
registry, we will use the second endpoint. Whenever the docker
daemon pulls from the buildset registry, it will use the first.
Change-Id: I296029068b5ef28ee56543741fe8c8deeefb5dfa
2019-02-21 13:49:49 -08:00
|
|
|
volumes:
|
|
|
|
- "{{ buildset_registry_root}}/certs:/certs"
|
|
|
|
- "{{ buildset_registry_root}}/auth:/auth"
|
2019-01-31 13:44:04 -08:00
|
|
|
- name: Set registry information fact
|
|
|
|
set_fact:
|
|
|
|
buildset_registry:
|
|
|
|
host: "{{ ansible_host }}"
|
|
|
|
port: 5000
|
2019-03-01 15:52:01 -08:00
|
|
|
proxy_port: 5001
|
2019-01-31 13:44:04 -08:00
|
|
|
username: zuul
|
|
|
|
password: "{{ registry_password }}"
|
|
|
|
cert: "{{ certificate }}"
|
|
|
|
- name: Return registry information to Zuul
|
|
|
|
zuul_return:
|
|
|
|
data:
|
|
|
|
buildset_registry: "{{ buildset_registry }}"
|