想了解一下云计算相关的知识，正好公司在用AWS，做一个基本的学习和了解。

云计算是通过 Internet 云服务平台按需提供计算能力、数据库存储、应用程序和其他 IT 资源，采用按需支付定价模式。
云计算包含三个主要类型，通常被称作：基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。

Amazon Web Services (AWS) 是一个安全的云服务平台，提供计算能力、数据库存储、内容交付以及其他功能来帮助实现业务扩展和增长。

AWS所有的Service：

申请12月免费账户

这没什么好说的，申请入口：AWS Free Tier，填写正确的信息就好了，要写正确的信用卡号和手机号以做验证，要不然不能申请成功。

申请成功后，登录就可以进入到Console。

创建Billing Alarm

尽管是免费的账户，还是设置一个Alarm好一些，万一花了钱就不好了，而且还是美元。

1. 在账户下的‘My Billing Dashboard’中设置，
2. 在‘Alert& Notifications’中Enable你的Monitor your estimated charges，
3. 选择‘Receive Billing Alerts’，保存，并点击‘Manage Billing Alerts’，
4. 到‘CloudWatch -> Alarms - Billing’，
5. Create Alarm，设置Exceed钱数和接受邮件地址，
6. 去设置的邮箱Verify，Alarm States is OK, 到此创建成功。

接下来，会把各个常用模块做个简单学习。

在上一家公司的时候就想过这个问题，但是一直没有深思考，说一下自己的一些见解，仅代表个人看法，如有不妥，还请指正。

工作价值：工资

我一直觉得工资不是评判一个人价值的唯一指标，就像考试第一名并不能代表你就是最优秀的学生。金钱/成绩确实很重要，但不是唯一。

但是从另一个角度想想，工资是不是公司衡量你工作价值的一个标准？工资是不是能反应出你的能力和努力后的成长？如果你的工资不高或者涨的不多，你有没有思考过，是不是因为自身的能力在标准之下？

为什么追求高工资

如今的我们跟上一辈的不同之处，还在于我们以近乎全裸的方式来到大城市，一无所有，没有亲戚邻居的帮衬，一切都得靠自己去努力，而大城市里的一切又是那么的昂贵，怎么才能活下去？怎么才能在这里扎根？这是要直面的且最基本的需求，所以追求高工资就也无可厚非。其实大家都是普通人，绝大多数人都只能通过努力工作来改变自己的命运，过上所谓的体面生活，而工资对普通人可以说是唯一的收入来源，有的人甚至以牺牲健康的代价去拼命加班，去挣更多的工资，不就是希望自己能在这个所谓的大都市里站住脚，让自己能有安全感。

活过而立之年，再想想，人追求越来越高的工资，真的就是单纯的为了追求金钱，追求物质？从人的需求层次来看，人最终追求的应该就是自由选择的权利，去做自己想做的事。从古至今来看，金钱好像是能够获得这种权利最容易的方式。

保持工资持续增长

从个人自身来看，你要舍得投资自己(ROI最高)，不断输入，去努力，去提升自己的价值，相信不断成长的你，工资也会呈上升曲线。

如今是一个‘大众创业，万众创新’的时代，是一个在别人嘴里站在风口猪都会飞的时代，也就是大家一直都在说的做事要顺势而为，其实工资也一样，在一个夕阳产业里，你再努力，工作价值再大，工资的增长未必能达到你的预期。所以要选对行业，站对队。

今年的清明节很不简单，竟然下起了雪，风不小，但是也没有那么的冷。

本来打算是去天文馆的，去的晚，票都售罄了，就去了它隔壁。

花了点时间把项目目前整个部署的流程从头到尾详细的梳理了一遍，了解了部署中的一些细节。目前这个过程算是半自动化的吧，在部署的过程中用到以下工具：

• Jenkins
• Git
• Artifactory
• Rundeck
• Salt

大概的示意图：

1. pipeline job
2. push to artifactory(jar, deb, zip)
3. salt configuration and work with Git
4. check deploy build version

再慢慢深入一些，能从AWS-Terraform-Salt-Automation，做到真正的全自动化。

持续集成(Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

持续交付(Continuous deliver)是一种软件工程手法，利用技术和工具快速地交付生产阶段的代码。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署(continuous deployment)是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。

整理东西，发现在学校的美术课，课余时间，还画不不少的画，Mark一下。以后每个学期整理一次。

States是SaltStack中的配置语言，在日常进行配置管理时需要编写大量的States文件。如安装软件啊，更改配置啊等，就需要编写states sls文件（描述状态配置的文件）去描述和实现这些功能。编写states sls文件一般是是YAML语法格式，也支持使用Python语言来编写。
定义例子：

1
2
3
4
5
6
7

apache: #state名称：apache
  pkg: #管理对象类型：pkg，进行软件安装（yum、apt）
    - installed #pkg要执行的方法：install，如未安装就进行安装
  service: #管理对象类型：service，管理系统守护进程
    - running #service要执行的方法：running，如未运行就进行启动
    - require: #关键字require，确保apache服务只有在成功安装软件包后才会启动
      - pkg: apache

State Tree

Top file:配置管理入口文件，和pillar类似，指定minions需要完成那些配置管理，默认为top.sls
注：在定义top.sls时,会先找apache/init.sls,如果没有的话，会找
apache.sls

1
2
3

　　base:
　　　　'*':
　　　　  - apache

配置

跟系统文件树一样，salt state文件也有自己的树系统，这通过配置文件中的file_roots配置

1
2
3
4

#在/etc/salt/master 中配置下面选项，指定salt state的根目录在/srv/salt
file_roots:
  base:
    - /srv/salt

修改master配置文件后需要重启。

创建Top文件

在/srv/salt目录下创建一个top.sls文件，这个文件提供了其它文件的映射。

1
2
3
4
5

[root@Automation salt]# vi top.sls
[root@Automation salt]# cat top.sls 
base:
  '*':
    - webserver

创建State文件

在top.sls相同的目录下，创建一个名为webserver.sls的空文件，也可以在同目录下创建一个文件夹webserver，在里边创建init.sls。

1
2
3
4
5

[root@Automation salt]# vi webserver.sls
[root@Automation salt]# cat webserver.sls 
httpd:                  
  pkg:                  
    - installed

执行Salt State

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[root@Automation salt]# salt '*' state.highstate
192.168.244.130:
----------
          ID: httpd
    Function: pkg.installed
      Result: True
     Comment: Package httpd is already installed.
     Started: 20:54:04.497245
    Duration: 2334.569 ms
     Changes:   

Summary
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1

master将会指导所有的目标minions运行state.highstate。
当minion执行highstate，它将会下载top文件中匹配的内容，minion将表达式中匹配的内容下载、编译、执行。一旦完成，minion将返回所有的动作执行结果和所有更改。

Grains VS Pillar

Grains

静态数据，当Minion启动的时候收集的MInion本地的相关信息。不重启minion，这些信息数据是不会改变的。

数据查询

• 列出主机的详细信息:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  [root@Automation ~]# salt 192.168.* grains.items 192.168.244.130: ---------- SSDs: biosreleasedate: 07/02/2015 biosversion: 6.00 cpu_flags: - fpu - vme - de - pse - tsc - msr - pae - mce ......

• 列出所有主机的系统版本:

  1 2 3 4 5

  [root@Automation salt]# salt '*' grains.item os 192.168.244.130: ---------- os: CentOS

• 直接获得内容

  1 2 3

  [root@Automation salt]# salt '*' grains.get os 192.168.244.130: CentOS

目标选择

1
2
3

[root@Automation salt]# salt -G 'os:Centos' test.ping 
192.168.244.130:
    True

配置管理

1. 修改minion - /etc/salt/minion

   1 2 3 4 5 6 7 8 9 10

   # Custom static grains for this minion can be specified here and used in SLS # files just like all other grains. This example sets 4 custom grains, with # the 'roles' grain having two values that can be matched against. grains: roles: - webserver - memcache deployment: datacenter4 cabinet: 13 cab_u: 14-15

   重启服务验证：

   1 2 3 4 5

   [root@Automation salt]# salt '*' grains.item deployment 192.168.244.130: ---------- deployment: datacenter4

2. 基于文件 - /etc/salt/grains

   1 2	[root@Automation salt]# cat grains centos: minion

   重启服务验证：

   1 2 3 4 5

   [root@Automation salt]# salt '*' grains.item centos 192.168.244.130: ---------- centos: minion

3. _grains目录自定义grain
   grains脚本目录，必须是base下创建_grains目录（如：/srv/salt/_grains）
   创建一个python脚本在/srv/salt/_grains目录下

   1 2 3 4 5 6 7 8 9 10 11 12

   [root@Automation _grains]# cat my_grains #!/usr/bin/env python #-*- coding: utf-8 -*- def my_grains(): # 初始化grains字典 grains = {} # 设置字典中的key-value grains['eb'] = 'eb' grains['add'] = 'beijing' # 返回字典 return grains

   通过master同步脚本文件至每台minion

   1	salt '*' saltutil.sync_grains

   文件放在minion主机的/var/cache/salt/minion/extmods/grains目录下

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   [root@Automation salt]# tree minion minion ├── extmods │   └── grains │   ├── my_grains.py │   └── my_grains.pyc ├── files │   └── base │   └── _grains │   └── my_grains.py ├── module_refresh └── proc 6 directories, 4 files

   在Master上验证：

   1 2 3 4 5

   [root@Automation salt]# salt '*' grains.item add 192.168.244.130: ---------- add: beijing

grains优先级（item名称相同的情况下）： 系统自带 > grains文件写到 > minion配置文件写的 > 自己写的脚本

SaltStak用下面的方式来远程执行命令（run shell commands, update packages, and distribute files to all managed systems simultaneously. ）：

• cmd 模块是常用的执行远程命令模块，具有强大的功能

  1 2 3 4 5

  [root@Automation ~]# salt 192.168.244.130 cmd.run 'ls /etc/salt' 192.168.244.130: minion minion.d pki

• sys.doc: 类似linux的man命令，可以显示minion支持的模块的详细操作说明

  1 2 3 4 5 6 7 8 9 10 11

  [root@Automation ~]# salt 192.168.244.130 sys.doc pkg.version 'pkg.version:' Returns a string representing the package version or an empty string if not installed. If more than one package name is specified, a dict of name/version pairs is returned. CLI Example: salt '*' pkg.version <package name> salt '*' pkg.version <package1> <package2> <package3> ...

• 安装package

  1 2 3 4 5 6 7 8

  [root@Automation ~]# salt 192.168.244.130 pkg.install cowsay 192.168.244.130: ---------- cowsay: ---------- new: 3.03-8.el6 old:

只是简单介绍一下命令执行，saltstack有非常多的模块来进行服务器管理，有需要再深入。