Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
gitlab-foss
提交
c91168c0
G
gitlab-foss
项目概览
李少辉-开发者
/
gitlab-foss
通知
15
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
gitlab-foss
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
c91168c0
编写于
8月 03, 2016
作者:
A
Achilleas Pipinellis
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Small refactor on Registry troubleshooting
[ci skip]
上级
2c9cce0f
变更
1
显示空白变更内容
内联
并排
Showing
1 changed file
with
23 addition
and
26 deletion
+23
-26
doc/container_registry/troubleshooting.md
doc/container_registry/troubleshooting.md
+23
-26
未找到文件。
doc/container_registry/troubleshooting.md
浏览文件 @
c91168c0
...
...
@@ -5,27 +5,27 @@
1.
Check to make sure that the system clock on your Docker client and GitLab server have
been synchronized (e.g. via NTP).
2.
If you are using an S3-backed
r
egistry, double check that the IAM
2.
If you are using an S3-backed
R
egistry, double check that the IAM
permissions and the S3 credentials (including region) are correct. See
[
the
sample IAM policy
](
https://docs.docker.com/registry/storage-drivers/s3/
)
for more details.
3.
Check the
r
egistry logs (e.g.
`/var/log/gitlab/registry/current`
) and the GitLab production logs
3.
Check the
R
egistry logs (e.g.
`/var/log/gitlab/registry/current`
) and the GitLab production logs
for errors (e.g.
`/var/log/gitlab/gitlab-rails/production.log`
). You may be able to find clues
there.
# Advanced Troubleshooting
#
#
Advanced Troubleshooting
NOTE:
The following section is only recommended for experts.
>**NOTE:**
The following section is only recommended for experts.
Sometimes it's not obvious what is wrong, and you may need to dive deeper into
the communication between the Docker client and the
r
egistry to find out
the communication between the Docker client and the
R
egistry to find out
what's wrong. We will use a concrete example in the past to illustrate how to
diagnose a problem with the S3 setup.
##
Example:
Unexpected 403 error during push
##
#
Unexpected 403 error during push
A user attempted to enable an S3-backed
r
egistry. The
`docker login`
step went
A user attempted to enable an S3-backed
R
egistry. The
`docker login`
step went
fine. However, when pushing an image, the output showed:
```
...
...
@@ -44,11 +44,11 @@ error parsing HTTP 403 response body: unexpected end of JSON input: ""
```
This error is ambiguous, as it's not clear whether the 403 is coming from the
GitLab Rails application, the Docker
r
egistry, or something else. In this
GitLab Rails application, the Docker
R
egistry, or something else. In this
case, since we know that since the login succeeded, we probably need to look
at the communication between the client and the
r
egistry.
at the communication between the client and the
R
egistry.
The REST API between the Docker client and
r
egistry is
[
described
The REST API between the Docker client and
R
egistry is
[
described
here
](
https://docs.docker.com/registry/spec/api/
)
. Normally, one would just
use Wireshark or tcpdump to capture the traffic and see where things went
wrong. However, since all communication between Docker clients and servers
...
...
@@ -56,12 +56,12 @@ are done over HTTPS, it's a bit difficult to decrypt the traffic quickly even
if you know the private key. What can we do instead?
One way would be to disable HTTPS by setting up an
[
insecure
r
egistry
](
https://docs.docker.com/registry/insecure/
)
. This could introduce a
R
egistry
](
https://docs.docker.com/registry/insecure/
)
. This could introduce a
security hole and is only recommended for local testing. If you have a
production system and can't or don't want to do this, there is another way:
use mitmproxy, which stands for Man-in-the-Middle Proxy.
## mitmproxy
##
#
mitmproxy
[
mitmproxy
](
https://mitmproxy.org/
)
allows you to place a proxy between your
client and server to inspect all traffic. One wrinkle is that your system
...
...
@@ -70,10 +70,9 @@ needs to trust the mitmproxy SSL certificates for this to work.
The following installation instructions assume you are running Ubuntu:
1.
Install mitmproxy (see http://docs.mitmproxy.org/en/stable/install.html)
2.
Run
`mitmproxy --port 9000`
to generate its certificates. Enter CTRL-C to quit.
3.
Install the certificate from ~/.mitmproxy to your system:
1.
Run
`mitmproxy --port 9000`
to generate its certificates.
Enter
<kbd>
CTRL
</kbd>
-
<kbd>
C
</kbd>
to quit.
1.
Install the certificate from
`~/.mitmproxy`
to your system:
```sh
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
...
...
@@ -87,24 +86,22 @@ Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks
in
/etc/ca-certificates/update.d....done.
```
## Verifying mitmproxy certifiactes
To verify that the certificates are properly install, run:
To verify that the certificates are properly installed, run:
```
sh
mitmproxy
--port
9000
```
This will run mitmproxy on port
9000
. In another window, run:
This will run mitmproxy on port
`9000`
. In another window, run:
```
sh
curl
--proxy
http://localhost:9000 https://httpbin.org/status/200
```
If everything is setup correctly,
then
you will see information on the mitmproxy window and
If everything is setup correctly, you will see information on the mitmproxy window and
no errors from the curl commands.
## Running the Docker daemon with a proxy
##
#
Running the Docker daemon with a proxy
For Docker to connect through a proxy, you must start the Docker daemon with the
proper environment variables. The easiest way is to shutdown Docker (e.g.
`sudo initctl stop docker`
)
...
...
@@ -118,10 +115,10 @@ docker daemon --debug
This will launch the Docker daemon and proxy all connections through mitmproxy.
## Running the Docker client
##
#
Running the Docker client
Now that we have mitmproxy and Docker running, we can
now attempt to login and push a container
image. You may need to run as root to do this. For example:
Now that we have mitmproxy and Docker running, we can
attempt to login and push
a container
image. You may need to run as root to do this. For example:
```
sh
docker login s3-testing.myregistry.com:4567
...
...
@@ -141,4 +138,4 @@ The above image shows:
What does this mean? This strongly suggests that the S3 user does not have the right
[
permissions to perform a HEAD request
](
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html
)
.
The solution: check the
[
IAM permissions again
](
https://docs.docker.com/registry/storage-drivers/s3/
)
.
Once the right permissions were set, the error w
ent
away.
Once the right permissions were set, the error w
ill go
away.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录