How to Debug Common Docker Errors?

hello my name is
paul pan from jefferson sport on today’s
short video i’m gonna
demonstrate to you how to deal about
common docker arrows
let’s jump in with an example
so i’m gonna try to log into my docker
registry
and it felt with the v2 request okay so
the first technique i’m going to do is
trying to run the v2
uh curl command to hit this v2
location
without authentication as you can see i
got a full
one from artifactory this is expected
but i’m also expected a realm
in the return header okay i’m not seeing
that so something is wrong with
artifactory
uh handling this request let’s check why
so i go to the log folder of art factory
and i’m going to tell
the artifactory
request log
and i’m going to grab four
on the youtube and the v2 request
好的,我会再次尝试我的日志
okay and i can immediately see that this
is going to the v2 endpoint
with a 401 but i’m not expecting it to
hit directly at v2 with the subdomain
method that i’m configured
uh to demonstrate here is an example
of
how the subdomain method responsive
configuration is different from the
others okay
so when it hit the
反向公关oxy i’m expecting to rewrite
the v2 request
to artifactory api docker prefixed with
the repository name i’m passing
i’m not seeing it in the request log so
something must be wrong with my reverse
proxy settings
let’s take a look at what my reverse
proxy settings is
so
so as you can see i am using a reverse
proxy settings
uh with subdomain method
so things looks good except my
server name here does not match what my
server name was provided in the dark
login command
so let’s try to modify it
so i modify my configuration
and uh let’s try to
restart the engine apps
okay now let’s restart it let’s do a
darker login again
and now it is successful okay
so uh so here as you can see comparing
to the
uh access direct access method the
things i need to pay attention to the
反向公关oxy of subdemand is that
in the server name i need to match in my
docker
host exactly so that it was able to get
the repository name
and do the rewrite of the v2 request
correctly
uh some additional settings in the world
反向公关oxy that we need to pay
attention to
is the extra frog override base url
so this url is going to be returned by
artifactory
and that’s how we get the the realm url
in the return
note that this url has the port
which is going to be grabbed from the
nginx uh settings here the host and the
server port
in terms of more complicated settings
such as
uh in a kubernetes environment it’s
often uh
uh it’s common to see that your client
is hitting a low balancer first before
you hit the reverse proxy
while the uh example that i demonstrate
the duck client hit
the worst budget directly so he was
able to get the correct server port
from from just the request however if
you have a load balancer in front of the
worst proxy and you’re terminating ssl
at the load balancer chances are when
the request hit from
low balance or hit nginx the port has
already been changed
okay so in the default settings we’re
relying on that with
the settings to automatically get the
server port from the request
but if you have a load balancer in front
you might want to
hard code the server port to be exactly
the port that your load balancer is
listed not
otherwise the first need to request
is going to be successful but when when
you do
actually do the login it will fail
um some additional technique i often use
to debug in a kubernetes environment
is the port forward uh command
uh a port forward will will allow you to
forward
a specific report or service directly to
your local host
uh when debugging network issues
especially
uh darker on kubernetes uh uh docker
with art factory on kubernetes uh
it is quite hard to isolate
each network component so the port
forward will allow you to bypass
certain network components all together
to test your settings or test if simply
the request was able to
reach artifactory or not
okay so that concludes my session for
the day if you have any questions and
comments feel free to leave below
and until next time