证书链合并

浏览器报错的证书链的问题,我们一般会有三种证书:

  • RootCA.crt(rCA,被信任的根证书)
  • IntermediateCA.crt(mCA,某些厂商有多个中间证书)
  • server.crt(sCA,通过CSR签下来的证书)

某些厂商的rCA和mCA是需要用户自己下载的。为了让浏览器能够信任我们的证书,我们需要配置一条完整的证书链,证书链由sCA和mCA构成就好,rCA是浏览器内置,不需要服务器给提供。nginx配置证书链的时候,就是指定一个证书文件,这个文件中含有我们整个证书链的所有证书就好,证书合并的时候,

正确的合并方法: 是把 mCA 合并到 sCA 中。当有多个 mCA 文件时,mCA 从下级到上级(根证书为最上级)依次合并到 sCA 中。在这个过程中,rCA 被视为多余的文件。

# Combined Certificates

-----BEGIN CERTIFICATE-----
...... sCA ......
------END CERTIFICATE------

-----BEGIN CERTIFICATE-----
...... mCA (lower) ......
------END CERTIFICATE------

-----BEGIN CERTIFICATE-----
...... mCA (upper) ......
------END CERTIFICATE------

证书链的问题解决后,基本应该就可以正常工作了。

.crt服务器证书文件直接通过记事本打开,.cer中级证书也直接通过记事本打开,然后按照如上规则,将两个文件合并(服务器证书内容在最上面,中级证书内容在下面),最后直接使用合并后的文件即可,这样就不会再报中级证书(证书链)的问题了。

注:实际上.crt跟.cer证书文件内容一样,只是扩展名不同而已。

注:服务器证书包含.crt和.key文件

附证书链检测网站: https://csr.chinassl.net/ssl-checker.html

k8s 命令简写配置

增加如下到用户目录的 .bashrc

alias kug='kubectl get'
alias kua='kubectl apply -f'
alias kuds='kubectl describe'
alias kud='kubectl delete'
alias kued='kubectl edit'
alias kuex='kubectl exec'

jenkins agent 部署

如果jenkins 主节点不能直接连接待部署项目的服务器A,但是A可以访问互联网,主节点也暴露在互联网上,可以通过在A所在的网络的选一台B主机安装agent ,通过这个agent来构建和发布。

相关配置注意点:

  • agent启动方式选择 “通过java Web启动代理”;
  • agent 配置标签,用法选择“只允许运行绑定到这台机器的Job”
  • 工具位置配置 agent中nodejs 安装的路径
  • agent 需要安装 git ,nodejs, agent需要 git, maven,node.js, java(以上都可以在全局工具配置自动安全), rsync(部署同步包到目的主机,双方都要装)
  • nodejs目录设置777权限,保证agent可以下载相关的编译依赖包 chmod -R 777 [node目录]
    自动部署,这部省略
  • 配置 JAVA_HOME 配置 ,全局默认路径/usr/lib/jvm/default-java (我的master),所以agent,安装了open-jdk要有这个目录,并且link到对应的jkd程序目录
  • agent网络,要允许访问,git-88, jenkins master 8087-8088 ,nexus 88(maven包和npm包)

在master上新建节点完成上面的操作后,返回节点列表,此时的点击显示未连接状态。点解刚创建的节点名称“test”,如下图

点击如图2的agent.jar 下载后传到agent所在服务器,然后在agent节点运行给出的命令启动agent服务。

启动后等待一会,就可以看到节点列表显示已经连接状态。

说话–金字塔原理

如何设计有吸引力的开场白

情景——>冲突———->疑问————>解答

情景S:自进入21世纪以来,人群结构中的“老龄化”已经呈现明显的趋势。
冲突C:然而在市场调查中发现,虽然老年人越来越多,然而他们在服装购买方面却存在着各种各样的困难,在商场中很难找到老年人专柜,老年人也没有自己的“名牌”。
疑问C:如何满足老年人的服装购买需要?
回答A:作为专业的服装生产和销售企业,我们有必须设计一个专门针对老年人的服装品牌。

四大疑问:是什么what 为什么why 怎么做 how 好不好

微服务组件

zuul

Zuul是Spring Cloud全家桶中的微服务API网关

所有从设备或网站来的请求都会经过Zuul到达后端的Netflix应用程序。作为一个边界性质的应用程序,Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各种filter实现如下功能:

  • 认证和安全 识别每个需要认证的资源,拒绝不符合要求的请求。
  • 性能监测 在服务边界追踪并统计数据,提供精确的生产视图。
  • 动态路由 根据需要将请求动态路由到后端集群。
  • 压力测试 逐渐增加对集群的流量以了解其性能。
  • 负载卸载 预先为每种类型的请求分配容量,当请求超过容量时自动丢弃。
  • 静态资源处理 直接在边界返回某些响应。

Eureka

MyBatis

  • MyBatis是支持普通SQL查询,存储过程和高级映射的优秀持久层框架。
  • MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。
  • MyBatis可以使用简单的XML或注解用于配置和原始映射,将接口和Java的POJO(Plain Old Java Objects,普通的Java对象)映射成数据库中的记录.

apollo配置中心快速上手

Apollo是什么?


现在是微服务大行其道的时代,但是每一个服务都有自己的配置(包括参数配置、服务器地址配置、功能开关等)。如果我们基于Springboot开发的话,这些东西我们一般都会定义在application.properties里面。但是这样每当配置需要修改的时候就显得异常的麻烦,传统的通过配置文件、数据库配置完全不能满足要求。

在这种情况下,诞生了很多的统一配置的服务,虽然springcloud有自己的config配置中心,但是个人感觉并不好用,而且也不贴合我们国内的开发习惯,所以我们来介绍一下Apollo配置中心。

Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性。

文章详细链接

ansible 的模块

ansible-doc modulename 模块用法的查询

shell

playbook tasks下多条命令的写法

- name: use ";"
  shell:  command 1 ; command 2

#方法二
- name: Install prerequisites
  shell:
    chdir: '{{ zuul.project.src_dir }}'
    executable: /bin/bash
    cmd: |
      set -e
      set -x
      echo "IPV4_ADDRS_SAFE_TO_USE=10.1.0.0/20" >> localrc
      ./tools/install_prereqs.sh

uesr

添加删除用户,修改密码。

修改密码 ansible host -m user -a 'name=root password="加密的密码"’

密码加密方法python交互界面:

[root@test-hub .ssh]# python3
Python 3.6.8 (default, Nov 16 2020, 16:55:22) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import crypt
>>> crypt.crypt("admin@123")
'$6$Ag2/sdXufJ0CY2pP$XkxspT1V/sf3O7TXTcGZk5Kmd6YlxZtwezzIlvH/GNHeeWC14n54OpEE0oSg5FtDV9glFs.bdwXL.8IY8LiM51'
>>> 

setup

服务器的硬件信息

ansible host -m setup -a ‘filter=”*mem*”‘

git的相关名词解析

origin: 代表远端仓库的别名(比如远端仓库地址 http://github.com/jimywu19/py.git),可任意修改其他名字。

分支: 指向 commit 对象的可变指针.

HEAD: 指向你正在工作中的本地分支的指针,可以理解为当前分支的别名

git merge 使用&&分支开发

一、创建分支dev并切换到分支

git checkout -b dev

二、开发分支(dev)上的代码达到上线的标准后,要合并到 master 分支
(说明:以下代表git的dev分支已经有最新代码,在本地合并)

## 场景说明:dev 分支由开发人员甲写完代码并已经推送到git的dev分支,master管理员来做分支合并工作
git checkout dev
git pull
git checkout master
git merge dev
git push -u origin master

三、当master代码改动了,需要更新开发分支(dev)上的代码

#场景说明: dev分支开发人员操作,
git checkout master 
git pull 
git checkout dev
git merge master 
git push -u origin dev

官网链接 Git 分支 – 分支的新建与合并

四、个人理解:

经常会忘记,mergn是怎么样的一个操作。是A并到B,还是B并到A.做下记录
新的东西在dev, dev 合并到master
那基点是master , git merge 后面跟的是 dev
总结,合并到哪里,需要先checkout到那里。

# 场景说明:以下为dev分支开发者视角,自己开发,自己有权合并到master
#创建并切换到分支
git checkout -b dev

#提交开发好的代码
git add .
git commit -m "commit infomation"
git push origin dev

#切回master分支
git checkout master
git pull master

#把本地分支合并到master
git merge dev

#把本地合并后的master同步到远程
git push orign master
另外解释下 git push [<repository>]  [<refspec>] ,