mysql

查询当前的部署模式

部署主从

主服务器配置

修改配置文件 /etc/my.cnf

[mysqld]
log-bin=mysql-bin #开启二进制日志
server-id=1 #设置server-id

重启mysql,登录mysql控制台,创建用于同步的用户账号:

mysql> CREATE USER 'repl'@'123.57.44.85' IDENTIFIED BY 'slavepass';#创建用户
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'123.57.44.85';#分配权限
mysql> flush privileges;   #刷新权限

查看master状态,记录二进制文件名(mysql-bin.000003)和位置(73):

mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73       | test         | manual,mysql     |
+------------------+----------+--------------+------------------+

从服务器配置

同样找到my.cnf配置文件,添加server-id

[mysqld]
server-id=2 #设置server-id,必须唯一

重启mysql,打开mysql会话,执行同步SQL语句(需要主服务器主机名,登陆凭据,二进制文件的名称和位置):

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='182.92.172.80',
    ->     MASTER_USER='rep1',
    ->     MASTER_PASSWORD='slavepass',
    ->     MASTER_LOG_FILE='mysql-bin.000003',
    ->     MASTER_LOG_POS=73;

启动slave同步进程

mysql>start slave;

查看slave状态:

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 182.92.172.80
                  Master_User: rep1
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000013
          Read_Master_Log_Pos: 11662
               Relay_Log_File: mysqld-relay-bin.000022
                Relay_Log_Pos: 11765
        Relay_Master_Log_File: mysql-bin.000013
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 

当Slave_IO_Running和Slave_SQL_Running都为YES的时候就表示主从同步设置成功了

还可以用到的其他相关参数:

binlog-do-db:指定mysql的binlog日志记录哪个db
Replicate_Do_DB:参数是在slave上配置,指定slave要复制哪个库

在master上设置binlog_do_弊端:
1、过滤操作带来的负载都在master上
2、无法做基于时间点的复制(利用binlog)。

需要注意的是最好在从服务器的my.cnf里设置read_only选项,防止发生意外(连接用户不能有SUPER权限,否则无效)。

记得先手动同步一下主从服务器:

  • 数据量小:可以用mysqldump,它有一个master-data参数很有用,通过使用此参数,导出的SQL文件里会自动包含CHANGE MASTER TO MASTER_LOG_FILE=’…’, MASTER_LOG_POS=…;,这样创建从服务器就更方便了。
  • 数据量大:不太适合使用mysqldump(慢),如果是myisam表的话,加上–lock-all-tables参数,如果是innodb表的话,加上–single-transaction参数。而应该采用拷贝文件的方式,请按如下操作步骤:

先在主服务器上锁定所有的表,以免在复制过程中数据发生变化:mysql> flush tables with read lock;

然后在主服务器上查询当前二进制文件的文件名及偏移位置:mysql > show master status;

然后停止主服务器上的MySQL服务:shell> mysqladmin -u root shutdown

注意:如果仅是MyISAM的话,可以不停止MySQL服务,但要在复制数据文件的过程中保持只读锁,如果是InnoDB的话,必须停止MySQL服务。

再拷贝数据文件:shell> tar -cvf /tmp/mysql-snapshot.tar .

拷贝完别忘了启动主服务上的MySQL服务了。

然后把数据文件应用到从服务器上,再次启动slave的时候使用,记得启动时加上skip-slave-start选项,使之不会立刻去连接master,再在从服务器上设置相关的二进制日志信息:

mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;

启动从服务器上的复制线程:mysql> start slave;

验证主从设置是否已经成功:mysql> show slave status\G;

数据库综述

关系型数据库

关系型数据库,是建立在关系模型基础上的数据库,其借助于集合代数等数学概念和方法来处理数据库中的数据。
主流的 oracle、DB2、MS SQL Server 和 mysql 都属于这类传统数据库。

NoSQL 数据库

NoSQL 数据库,全称为 Not Only SQL,意思就是适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。主要分为

  • 临时性键值存储(memcached、Redis)、
  • 永久性键值存储(ROMA、Redis)、
  • 面向文档的数据库(MongoDB、CouchDB)、
  • 面向列的数据库(Cassandra、HBase),

每种 NoSQL 都有其特有的使用场景及优点。

git flow规范

简介

•Git Flow是一套使用Git进行源代码管理时的一套行为规范
•Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践
•Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题
•Git Flow通过创建和管理分支,为每个分支设定具有特定的含义名称,并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离

Git Flow中的分支

•主分支

•master:随时可供在生产环境中部署的代码的分支
•develop:保存当前最新开发成果的分支

辅助分支

  • feature:用于开发新功能时所使用的分支
  • release:用于辅助版本发布的分支
  • hotfix:用于修正生产代码中的缺陷的分支

feature分支

接到一个新的功能的开发任务后,从develop分支发起,并push成为远程分支

命名规范:例如开发一个项目信息的功能,则创建的分支名为:feature-project-info

每天下班前push代码到远程,进行备份,防止本地电脑故障导致代码丢失。一般feature分支由单人开发维护,可视为个人分支,所以push的代码不稳定也不会影响他人

每个人只需要维护好自己的功能分支,无需与他人进行频繁的合并,极大的降低了冲突概率,降低了代码互相覆盖的风险,从而实现多人多功能的并行开发

若不同的feature分支之间有依赖关系,则等目标feature分支开发完成以后,直接pull目标feature分支即可,若需要协同开发,则多人使用同一条feature分支即可

功能相关的代码开发完毕,并通过自测稳定以后,合并回develop分支,并可以删除feature分支,feature分支的生命周期到此结束

注意事项:所有merge操作,必须使用–no-ff参数禁止fast forward合并,防止丢失合并历史信息,例:git merge –no-ff feature-project-info

feature分支额外自定义规范

  • 开发经理创建公共集成feature分支
  • 开发人员创建自己的feature分支,并进行开发
  • 开发完成并自测稳定以后,合并到公共集成feature分支上
  • 再由开发经理统一合并到develop分支上

release分支

•release分支是为发布新版本提供支持的分支,从最新的develop分支发起(已合并所有此次要上线的feature) •命名规范:一般以发布日期为分支名,如7月15日计划上线,则分支名为:release-0715或release-7.15 •发布测试环境应拉取此分支的代码进行打包(结合jenkins自动化部署) •测试中发现的bug,也直接在此分支进行修复,与可能还在往前演进的develop分支隔离并行,控制发布的代码范围,防止多余的功能代码被意外的发布上线 •测试通过后,由开发经理合并到master(master分支受保护,合并需要权限),然后使用master的代码进行打包,发布生产环境,发布后,并打上版本号的tag •发布上线后,需要将master合并回develop,将release分支中修改的bug同步,防止bug重现

release分支额外自定义规范

•多版本上线时间相近,并且需要进行功能点隔离时
•创建多条release分支,不同的公共集成feature分支直接合并到对应的release分支上
•而不是全部合并到develop分支上,从而达到不同的发布版本功能范围隔离的效果

hotfix分支

  • hotfix分支是版本上线后,在线上发现了bug,从master分支发起的紧急修复bug的分支
  • 由于它的发布属性,可以把它看作是计划外的release分支,也就是紧急发布分支
  • bug修复后,不但要合并到master,还要合并回develop,防止bug重现

Git Flow闭环全流程概览

  • 接到一个功能开发任务,创建对应的feature分支
  • 功能开发完成后,合并回develop
  • 从最新的已包含所有功能的develop上发起release分支
  • 从release分支打包发布测试环境,开始测试,修复bug
  • 测试完毕,合并回develop,合并到master,发布上线, 打tag
  • 线上发现bug,从master发起hotfix分支,修复后,合并回master与develop,在master上打上tag,方便回溯
  • 开启下一个流程

promethues

#gitlab集成的promethues配置文件
---
global:
  scrape_interval: 15s
  scrape_timeout: 15s
scrape_configs:
- job_name: prometheus
  static_configs:
  - targets:
    - localhost:9090
- job_name: redis
  static_configs:
  - targets:
    - localhost:9121
- job_name: postgres
  static_configs:
  - targets:
    - localhost:9187
- job_name: node
  static_configs:
  - targets:
    - localhost:9100
- job_name: gitlab-unicorn
  metrics_path: "/-/metrics"
  static_configs:
  - targets:
    - 127.0.0.1:8080
- job_name: gitlab_monitor_database
  metrics_path: "/database"
  static_configs:
  - targets:
    - localhost:9168
- job_name: gitlab_monitor_sidekiq
  metrics_path: "/sidekiq"
  static_configs:
  - targets:
    - localhost:9168
- job_name: gitlab_monitor_process
  metrics_path: "/process"
  static_configs:
  - targets:
    - localhost:9168
- job_name: kubernetes-nodes
  scheme: https
  tls_config:
    ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
    insecure_skip_verify: true
  bearer_token_file: "/var/run/secrets/kubernetes.io/serviceaccount/token"
  kubernetes_sd_configs:
  - role: node
    api_server: https://kubernetes.default.svc:443
    tls_config:
      ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
    bearer_token_file: "/var/run/secrets/kubernetes.io/serviceaccount/token"
  relabel_configs:
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+)
  - target_label: __address__
    replacement: kubernetes.default.svc:443
  - source_labels:
    - __meta_kubernetes_node_name
    regex: "(.+)"
    target_label: __metrics_path__
    replacement: "/api/v1/nodes/${1}/proxy/metrics"
  metric_relabel_configs:
  - source_labels:
    - pod_name
    target_label: environment
    regex: "(.+)-.+-.+"
- job_name: kubernetes-pods
  tls_config:
    ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
    insecure_skip_verify: true
  bearer_token_file: "/var/run/secrets/kubernetes.io/serviceaccount/token"
  kubernetes_sd_configs:
  - role: pod
    api_server: https://kubernetes.default.svc:443
    tls_config:
      ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
    bearer_token_file: "/var/run/secrets/kubernetes.io/serviceaccount/token"
  relabel_configs:
  - source_labels:
    - __meta_kubernetes_pod_annotation_prometheus_io_scrape
    action: keep
    regex: 'true'
  - source_labels:
    - __meta_kubernetes_pod_annotation_prometheus_io_path
    action: replace
    target_label: __metrics_path__
    regex: "(.+)"
  - source_labels:
    - __address__
    - __meta_kubernetes_pod_annotation_prometheus_io_port
    action: replace
    regex: "([^:]+)(?::[0-9]+)?;([0-9]+)"
    replacement: "$1:$2"
    target_label: __address__
  - action: labelmap
    regex: __meta_kubernetes_pod_label_(.+)
  - source_labels:
    - __meta_kubernetes_namespace
    action: replace
    target_label: kubernetes_namespace
  - source_labels:
    - __meta_kubernetes_pod_name
    action: replace
    target_label: kubernetes_pod_name

gitlab

部署

官网文档:https://about.gitlab.com/install/?test=capabilities#centos-8

以下为centos 8平台安装步骤:

#安装依赖,一般服务器openssh-server都已经安装并且启动
sudo dnf install -y curl policycoreutils openssh-server perl
##防火墙开启 80,443端口
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
systemctl reload firewalld

# 添加gitlab repo
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
##如果有外网地址解析,添加变量
EXTERNAL_URL="https://gitlab.example.com"

# 安装
dnf install -y gitlab-ee

##基础信息
配置文件 /etc/gitlab/gitlab.rb
安装目录/opt/gitlab   /var/opt/gitlab

备份还原

官方参考https://docs.gitlab.com/ee/raketasks/backup_restore.html

备份

gitlab-rake gitlab:backup:create #备份,默认位置/var/opt/gitlab/backups
gitlab-backup create ##GitLab 12.2 起使用这个命令

##备份配置文件
/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb
##可以运行如下命令备份配置文件,
##配置文件会保存在/etc/gitlab/config_backup/,
gitlab-ctl backup-etc

还原

还原前

sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# Verify
sudo gitlab-ctl status

gitlab-rake gitlab:backup:restore #还原,恢复的gitlab要和备份的版本完全相同

以上是12.1以前的版本。之后的是gitlab-backup create ;gitlab-backup restore

恢复后

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

重置root 密码

gitlab-ctl start 保证gitlab处于启动状态,&保证redis处于启动状态

gitlab-ctl start            #保证gitlab处于启动状态,&保证redis处于启动状态
gitlab-rails console production
irb(main):001:0>user = User.where(id: 1).first   #定位到gitlab 数据库中Users表中的一个用户,通常就是管理员用户admin@local.host
irb(main):002:0> user.password=12345678          #重置管理员密码为12345678
irb(main):003:0> user.password_confirmation=12345678   #确认管理员密码为12345678
irb(main):004:0> user.save!    #保存更改信息

用户权限

Guest:可以创建issue、发表评论,不能读写版本库

Reporter:可以克隆代码,不能提交,可以赋予测试、产品经理此权限

Developer:可以克隆代码、开发、提交、push,可以赋予开发人员此权限

MainMaster:可以创建项目、添加tag、保护分支、添加项目成员、编辑项目,一般GitLab管理员或者CTO才有此权限

helm

介绍

Helm 是一个 Kubernetes 的包管理工具,类似 Linux 的包管理器,如RedHat系的yum、Debian的apt,可以很方便的将之前打包好的 yaml 文件部署到 Kubernetes 上。Helm主要解决以下问题:1、把yaml作为一个整体管理。2、实现yaml的高效复用。3、实现应用级别的版本管理。

当前 Helm 已经升级到V3版本,相比于V2版本主要变化如下:

1、 最明显的变化是删除了 Tiller 。
2、 Release 名称可以在不同命名空间重用。
3、 支持将 Chart 推送至 Docker 镜像仓库中。
4、 使用 JSONSchema 验证 chart values。

Helm 有3个重要概念:
    1、helm: 一个命令行客户端工具,主要用于 Kubernetes 应用 chart 的创建、 打包、 发布和管理。
    2、Chart:应用描述,一系列用于描述 k8s 资源相关文件的集合。
    3、Release:基于 Chart 的部署实体,一个 chart 被 Helm 运行后将会生成对应的一个release;release是在 k8s 中创建出真实运行的资源对象。

下图是 Helm V2 与 Helm V3 的架构图对比:

V2版本的架构中,Tiller在Kubernetes集群中,Helm Client发请求给Tiller需要经过RBAC认证。而V3版本是Helm通过kubeconfig连接kube-apiserver,避免了使用者去配置RBAC权限。

安装

可以直接下载二进制文件 https://github.com/helm/helm/releases linux amd64

解压后 把helm 复制到bin目录 mv linux-amd64/helm /usr/local/bin/helm

如同yum、apt拥有仓库一样,Helm也有仓库,使用Helm默认仓库下载Chart比较慢,可以增加微软、阿里的仓库。

添加微软Chart仓库

helm repo add stable http://mirror.azure.cn/kubernetes/charts

使用

##查看 可用chart
$ helm search repo stable
##安装mysql
$ helm repo update              # Make sure we get the latest list of charts
$ helm install stable/mysql --generate-name  ##generate-name就是本地mysql的名字
                                             随机生成,
Released smiling-penguin
$ helm install wujy_mysql stable/mysql           #也可以自己定义名字

##查看已安装的released
$ helm ls
NAME             VERSION   UPDATED                   STATUS    CHART
smiling-penguin  1         Wed Sep 28 12:59:46 2016  DEPLOYED  mysql-0.1.0
##卸载一个release
$ helm uninstall smiling-penguin
Removed smiling-penguin

常用命令

查找 helm search <hub/repo> CHARTNAME
安装 helm install --name mem1 stable/memcached
获取状态信息 helm status mem1
列出 helm list [-a]
下载 helm get stable/redis
创建 helm create CHARTNAME
语法检测 helm lint CHARTNAME
打包 helm package CHARTNAME
显示状态 helm status NAME

linux swap分区

首先划分一个分区做swap

fdisk /dev/vdb

分区类型按”t“修改为82 Linux swap,保存

格式化分区 mkswap /dev/vdb2

启动swap分区 swapon /dev/vdb2

查看swap分区UUID blkid

/etc/fstab永久挂载 UUID=04820cf8-90b3-4bf9-8402-071352674b73 swap swap defaults 0 0

查看 free -h swapon -s

NFS subdir external provisioner

这个provisioner支持用已有的nfs动态的创建PV,下面记录下部署过程。

前提已经有一个k8s集群,一台nfs服务器。我的环境是1master ,2worker的k8s,用work2搭建了nfs

步骤如下:

1. 准备好nfs服务器的信息

确保你的k8s可以正常访问nfs服务器,服务器IP (192.168.157.130) , 共享目录(/public)

2. 下载 provisioner 文件


git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git
#切换到nfs-subdir-external-provisioner目录下

3. 安装RBAC授权相关的账号、角色、绑定

#编辑 deploy/rbac.yaml  deployment.yaml
#我把provisioner安装在kube-system命名空间,这个可以自己定义修改
$ NAMESPACE="kube-system"
$ sed -i'' "s/namespace:.*/namespace: $NAMESPACE/g" ./deploy/rbac.yaml ./deploy/deployment.yaml
$ kubectl create -f deploy/rbac.yaml -f deploy/deployment.yaml

4.配置provisioner

编辑deploy/deployment.yaml文件,修改image 为国内镜像,不然下载不下来(比如我的:registry.cn-hangzhou.aliyuncs.com/jimywu/nfs-subdir-external-provisioner:v4.0.0);

修改<YOUR NFS SERVER HOSTNAME> 和 <YOUR PATH>,我的分别为192.168.157.130,/public

其他的都保持默认,kubectl create -f deploy/deployment.yaml 安装

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: <YOUR NFS SERVER HOSTNAME>
            - name: NFS_PATH
              value: <YOUR PATH>
      volumes:
        - name: nfs-client-root
          nfs:
            server: <YOUR NFS SERVER HOSTNAME>
            path: <YOUR PATH>

5.部署 storage class

编辑 deploy/class.yaml 文件,增加5,6两行,把此storageclass设置为系统默认,这样创建PV时不用指明SC的名字。

  1 apiVersion: storage.k8s.io/v1
  2 kind: StorageClass
  3 metadata:
  4   name: managed-nfs-storage
  5   annotations:
  6     "storageclass.kubernetes.io/is-default-class": "true"
  7 provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'
  8 parameters:
  9   archiveOnDelete: "false"

最后 kubectl create deploy/class.yaml 部署。以上没有出错,基本已经完成部署。

设置默认storageClass

kubectl patch sc managed-nfs-storage -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:”true”}}}’

参考链接:官方git : https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner