Open ghost opened 5 years ago
I'm actively working on this role and Harbor can be a bit fiddly, specially because it sets its own Nginx inside and then you have sort of "duplicated" configuration of sorts sometimes.
Do you have it behind a proxy? If you do, you need to comment a line inside <harbor>/common/config/nginx.conf
(and have it set on your proxy).
proxy_set_header X-Forwarded-Proto $scheme
There'll be several instance of this line, you need to comment them all. This is what solved for me when I couldn't login. I'm adding somethings to the playbook to do this automatically.
If this doesn't work, you'll need to paste here the contents of /var/log/harbor
so that we can understand what's going on.
you might also want to check the proxy.log
first. 502 usually means nginx-photon
container failed to start. Permission problems, maybe?
I've just pushed new changes and they are fully working with my setup from beginning-to-end.
My setup, for your information, is that I run Harbor behind a NGINX proxy. Nginx has the HTTPS termination and harbor
runs on http mode.
Thanks for the changes! This wasn't what caused the error it seems. I am checking this further today. I do not use a reverse proxy in this setup
The issue is that
Mar 19 13:38:59 172.21.0.1 core[72254]: 2019-03-19T11:38:59Z [ERROR] [utils.go:101]: failed to connect to tcp://adminserver:8080, retry after 2 seconds :dial tcp: lookup adminserver on [fe80::1%2]:53: dial udp [fe80::1%2]:53: connect: cannot assign requested address
It is probably due to
Mar 23 16:45:45 172.21.0.1 adminserver[72254]: 2019-03-23T14:45:45Z [FATAL] [main.go:45]: failed to initialize the system: read /etc/adminserver/key: is a directory
I will check further EDIT: Date/time doesn't make sense but basically the logs loop on this error
Basically adminserver doesn't start and it is due to
Mar 23 16:45:45 172.21.0.1 adminserver[72254]: 2019-03-23T14:45:45Z [FATAL] [main.go:45]: failed to initialize the system: read /etc/adminserver/key: is a directory
but I still did not understand why that happens. I think that the compose command creates the binding as a directory initially because it does not exist not exist.
I am not yet sure how to solve that. Which element is supposed to create this key initially @nicholasamorim ?
This is what I found:
https://github.com/goharbor/harbor/issues/2208
To summarize: as for now secretkey_path in harbor.cfg should never be changed or if you have to change it you should remember to adjust paths in docker-compose.yml manually because they are hardcoded.
Does that aligns with your PR #9?
you should remember to adjust paths in docker-compose.yml manually because they are hardcoded.
This is what is done but automatically since we use Ansible, we can do that.
You have defaults on harbor_datadir
to /data
but if someones changes harbor_datadir
, that person won't notice why everything breaks without digging quite deep.
An alternative to that could be to set a default on harbor_secretkey_path
in https://github.com/nicholasamorim/ansible-role-harbor/blob/master/defaults/main.yaml and clearly mention how it works in the main README.
What do you think?
After the merge, this works but if we have multiple users only one gets created
Humm, that's funny, all my users get created. Can you share your structure for creating the users?
I'm sharing mine but not sure it's useful. I build it from another list, a master list of users.
harbor_users: "{{ harbor_users|default([]) + [ {'username': item.username, 'email': item.username ~ '@mycmopany.com', 'realname': item.name | default(item.username), 'has_admin_role': item.admin | default(false)} ] }}"
`harbor_users: "{{ DOCKER_REPO_USERS }}"`
from the playbook
DOCKER_REPO_USERS:
- username: "{{ SSH_USER }}"
password: "{{ INITIAL_PASSWORD }}"
email: name1@domain.com
realname: Name one
role_name: developer
role_id: 2
has_admin_role: true
- username: userbis
password: Password@455
email: name2@domain.com
realname: Name two
role_name: developer
role_id: 2
has_admin_role: true
Variable in another file
I updated to the latest version. Getting to the end of the corridor!
Creating users fail with the message below. Would you have any idea why?
In addition:
Here is my playbook: