你好,请问choerodon的一键部署脚本今天是否有改动?

你好! 请问choerodon的一键部署脚本是否有改动,昨天下午我部署成功了,今天重新部署就不行了,好奇怪!

没有改动哦

你好!
请问在一键部署的values.sh配置文件中,这个几个密码有关联性吗?我的密码按照以下设置是否正确?

############################  数据库配置  ############################
MYSQL_ROOT_PASSWORD="nipu8r"
MYSQL_USER="choerodon"
MYSQL_PASSWORD="nipu1y"
########################### Gitlab配置 ############################
# gitlab root用户密码,使用外部gitlab请忽略。(不能少于8位)
GITLAB_ROOT_PASSWORD="uipu15yt"
# 通过choerodon平台创建的用户,gitlab初始密码(不能少于8位)
GITLAB_USER_PASSWORD="uipu15yu"
########################### Minio 配置  ############################
# minio access key
MINIO_ACCESS_KEY="admin"
# minio secret key(不能低于8位)
MINIO_SECRET_KEY="yipu1rge"
########################### Harbar 配置  ############################
# Harbar管理员密码(长度8-20位,必须包含至少1个大写字母,至少1个小写字母,至少1个数字)
HARBOR_ADMIN_PASSWORD="jitWt15u"

没有关联的

哦,好的,谢谢!
我通过一键部署脚本搭建好了,发现有一个pod总是运行不正常
choerodon-devops-prod choerodon-gitlab-595b5769d5-4m74q 0/1 Running 1 12m
我查看了该pod的日志信息,日志报错如下,请问是什么原因啊?
==> /var/log/gitlab/gitaly/current <==
2018-10-09_09:48:53.47481 time=“2018-10-09T09:48:53Z” level=info msg=“dialing to target with scheme: “”” system=system
2018-10-09_09:48:53.47484 time=“2018-10-09T09:48:53Z” level=info msg=“ccResolverWrapper: sending new addresses to cc: [{/tmp/gitaly-ruby870658504/socket.0 0 }]” system=system
2018-10-09_09:48:53.47485 time=“2018-10-09T09:48:53Z” level=info msg=“ClientConn switching balancer to “pick_first”” system=system
2018-10-09_09:48:53.47499 time=“2018-10-09T09:48:53Z” level=info msg=“pickfirstBalancer: HandleSubConnStateChange: 0xc4204077e0, CONNECTING” system=system
2018-10-09_09:48:53.47528 time=“2018-10-09T09:48:53Z” level=info msg=“pickfirstBalancer: HandleSubConnStateChange: 0xc4204077e0, READY” system=system
2018-10-09_09:48:53.47764 time=“2018-10-09T09:48:53Z” level=info msg=“dialing to target with scheme: “”” system=system
2018-10-09_09:48:53.47782 time=“2018-10-09T09:48:53Z” level=info msg=“ccResolverWrapper: sending new addresses to cc: [{/tmp/gitaly-ruby870658504/socket.1 0 }]” system=system
2018-10-09_09:48:53.47783 time=“2018-10-09T09:48:53Z” level=info msg=“ClientConn switching balancer to “pick_first”” system=system
2018-10-09_09:48:53.47783 time=“2018-10-09T09:48:53Z” level=info msg=“pickfirstBalancer: HandleSubConnStateChange: 0xc4203ce280, CONNECTING” system=system
2018-10-09_09:48:53.47810 time=“2018-10-09T09:48:53Z” level=info msg=“pickfirstBalancer: HandleSubConnStateChange: 0xc4203ce280, READY” system=system

==> /var/log/gitlab/nginx/gitlab_error.log <==
2018/10/09 17:49:01 [error] 509#0: *91 connect() to unix:/var/opt/gitlab/gitlab-workhorse/socket failed (111: Connection refused) while connecting to upstream, client: 10.233.66.1, server: gitlab.example.choerodon.io, request: “GET /help HTTP/1.1”, upstream: “http://unix:/var/opt/gitlab/gitlab-workhorse/socket:/help”, host: “10.233.66.66:80”

==> /var/log/gitlab/nginx/gitlab_access.log <==
10.233.66.1 - - [09/Oct/2018:17:49:01 +0800] “GET /help HTTP/1.1” 502 2916 “” “kube-probe/1.8”

请耐心等待,gitlab启动会消耗很长时间。

请问下,我部署minio报
kubectl logs minio-544bc48d8d-9fclw -n c7n-system

You are running an older version of Minio released 4 months ago
Update: https://docs.minio.io/docs/deploy-minio-on-kubernetes

ERROR Unable to initialize backend: Unable to write to the backend.
> Please ensure Minio binary has write permissions for the backend.

删除当前minio的pod试一试呢,这种情况我们还没有遇到过,也建议到minio官方提issues

删除了很多次还是不行,我官网找找看

一键部署mysql和gitlab-mysql都报如下错,
Initializing database
2019-02-21T08:00:12.570890Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-02-21T08:00:12.574344Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2019-02-21T08:00:12.574389Z 0 [ERROR] Aborting

这个问题需要在 vi /etc/my.cnf 文件中加上 : explicit_defaults_for_timestamp=true或者在mysql配置文件中加上,看不到你们安装脚本代码不知道怎么处理这个问题,希望能帮助下,这边是你们潜在的客户

看报错信息是由于数据库第一次没有初始化成功而生成了一部分文件,而这部分文件导致后期mysql无法正常启动,请清空对应目录后重试

谢谢,一键部署的mysql文件是在哪里清空,容器中吗

以分步部署的mysql为例:

# 停止mysql运行
kubectl scale deployment -n c7n-system c7n-mysql --replicas=0

# 获取mysql持久化的物理路径
kubectl get pv -o  jsonpath={.spec.nfs}  $(kubectl get pvc -n c7n-system c7n-mysql-pvc -o go-template=pvc-{{.metadata.uid}})

# 得到以下返回结果,server代表所在的pod的ip,path代表持久化的物理路径
# map[server:10.233.26.14 path:/export/pvc-4fc6caf7-e6ee-11e8-b098-5254009543fb]

# nfs-provisioner的pod中,删除相应目录下数据
kubectl exec -it $(kubectl get po -l choerodon.io/infra=nfs-provisioner -n kube-system -o jsonpath="{.items[0].metadata.name}") -n kube-system bash
rm -rf /export/pvc-4fc6caf7-e6ee-11e8-b098-5254009543fb/*

# 启动mysql
kubectl scale deployment -n c7n-system c7n-mysql --replicas=1