Amazon Polly 是一项将文本转换为逼真语音的服务，让您可以构建支持聊天功能的应用程序，从而打造全新类别的具有语音功能的产品。它使用深度学习技术来合成类似于人声的语音。该服务提供了不同语言的各种语音。

对于外出的企业 IT 安全人员，有关 AWS 账户安全事件的电话呼叫警报可以带来极大的帮助。这些安全事件可以根据事件的严重性和优先级进行自定义。严重性和优先级较高的安全事件可以发送到通过电话呼叫报警的系统中。

对于电话呼叫报警，我会使用 Twilio，它提供了 API 功能，例如语音、视频和消息传送。当给定 AWS 账户中发生安全事件时，使用 Twilio 的平台能够以编程方式发布 API 调用，用于进行电话呼叫。Amazon Polly 将此文本警报转换为在电话呼叫上播放的语音消息。

解决方案概述

该解决方案包括两个系统，如以下架构图所示：

• 事件检测和通知系统
• 文本到语音转换系统

事件检测和通知系统与文本到语音转换系统彼此分离，这是因为后一个系统对用户定义的任何其他事件检测通用。在此博客帖子中，作为解决方案示例，我重点介绍文本到语音转换系统，并使用来自我之前博客帖子中介绍的事件检测和通知系统。

如架构图中所示。步骤 3 的警报消息发布到 Amazon SNS 主题，该 SNS 触发我们文本到语音转换系统中的 Lambda 函数。

1. 此 Lambda 函数解析 SNS 警报消息的主题，并使用 Amazon Polly 将文本转换为语音文件。
2. 此语音文件存储在 Amazon S3 存储桶中。
3. Twilio 使用语音文件的位置，对相关方进行出站呼叫并播放语音文件。请注意，您可以根据在使用语音文件进行出站呼叫之后的需求，为这些文件添加 Amazon S3 对象生命周期策略。

演示

先决条件

• 至少有一个事件检测和通知系统。例如，您可以设置对 AWS 账户根用户活动进行监视和通知
• 您将需要 Twilio 账户身份验证令牌来进行 API 调用。您可在此处注册免费 (试用) Twilio 账户。
• 会向您的 Twilio 账户分配一个电话号码。这是您接听电话呼叫报警时的主叫号码。
  
• 如果您使用的是试用账户，则需要确保对“被叫”电话号码进行验证。
  

部署步骤

以下部署步骤将部署“文本到语音转换”系统，如下图中所示。

1. 在 AWS CloudFormation 控制台中，选择 Create Stack。使用 CloudFormation JSON 模板 。选择 Next。(注意：中国和 AWS GovCloud (美国) 区域不支持 Amazon Polly。)
2. 在要部署事件检测和通知系统的区域中创建堆栈。
3. 输入以下参数详细信息，选择 Next，然后选择 Next：
   1. ToPhoneNo：Twilio 将拨打的电话号码。在电话号码前面加上“+国家/地区代码”，例如 +14561237890。
   2. FromPhoneNo：Twilio 进行呼叫时所用的虚拟电话号码。在您的 Twilio 账户中可以找到此信息。请参阅“先决条件”部分。
   3. TwilioAccntSid：输入 Twilio 账户 SID。当您在 https://www.twilio.com/ 上注册时提供此项
   4. TwilioAuthToken：输入 Twilio 身份验证令牌 ID。
   5. BucketName：输入您要创建的存储桶的名称。此存储桶将存储事件警报的语音文件。
   6. PollyVoiceId：输入您希望呼入警报的 Amazon Polly 语音。默认语音为“Amy”。
   7. LambdaS3Bucket：存储 Lambda 函数 zip 文件的 Amazon S3 存储桶的名称。
   8. LambdaS3Key：Lambda 函数 zip 文件的名称。这是 S3 对象的完整路径，带有前缀。例如，“dir1/dir2/lambdafunction.zip”。Lambda 函数 zip 文件可以从此博客帖子的 Lambda 函数部分中的链接下载。
4. 依次选择 Capabilities Acknowledgement 和 Create。此字段向堆栈提供权限来创建 IAM 角色和策略。这些角色和策略由 Lambda 函数用于执行特定操作，例如发布消息到 SNS 主题、列出账户别名等等。
5. CloudFormation 堆栈完成之后，检查 output 中提供的 Lambda 函数名
6. 现在，我们将触发器添加到此 Lambda 函数。转到 Lambda 控制台并选择刚刚创建的 Lambda 函数，然后选择 triggers 和 add trigger。
7. 在触发器框中，选择 SNS，并选择您希望用于电话呼叫的“事件检测和通知”系统的 SNS 主题。选择 Submit。
   
8. 现在，Lambda 函数已准备好，可由您的“事件检测和通知”系统的 SNS 主题触发。您可以根据需要，为各种事件检测和通知系统添加任意数量的触发器。在此处可以找到有关触发 AWS Lambda 的更多信息。

SNS 触发 Lambda 函数

在触发时，文本语音转换 Lambda 函数会解析 SNS 消息的主题。然后，它将此主题字段文本传递到 Amazon Polly 服务以将其转换为语音文件。将文本转换为语音文件之后，该文件存储在前一部分中由 CloudFormation 堆栈创建的 S3 存储桶内。

然后，它调用 Twilio API 进行电话呼叫，并播放来自 S3 存储桶的事件通知音频文件。

import boto3
import os
from contextlib import closing
import botocore.session
from botocore.exceptions import ClientError
session = botocore.session.get_session()
import logging
import uuid
import twilio
from twilio.rest import Client

import urllib
from urllib import request, parse
from urllib.parse import quote

logging.basicConfig(level=logging.DEBUG)
logger=logging.getLogger(__name__)

def lambda_handler(event, context):
    logger.setLevel(logging.DEBUG)
    logger.debug("Event is --- %s" %event)
    speak = event["Records"][0]["Sns"]["Subject"]
	
	# 将 SNS 消息的主题文本转换为 mp3 语音文件。
	
    polly = boto3.client('polly')
    response = polly.synthesize_speech( OutputFormat='mp3',
                                        Text = 'ALERT !' + speak,
                                        SampleRate='22050',
                                        VoiceId = os.environ['VoiceId']  
                                        )
    logger.debug("Polly Response is-- %s" %response)
    id = str(uuid.uuid4())
    logger.debug("ID= %s" %id)
    
    
    # 将 Amazon Polly 返回的语音流保存到 Lambda 的临时
    # 目录。如果有多个文本块，语音流
    # 将合并为单个文件。
    if "AudioStream" in response:
        with closing(response["AudioStream"]) as stream:
            filename=id + ".mp3"
            output = os.path.join("/tmp/",filename)
            with open(output, "wb") as file:
                file.write(stream.read())
	
	# 将语音 MP3 文件上传到 S3位置
	
    s3 = boto3.client('s3')
    s3upload_response = s3.upload_file('/tmp/' + filename, os.environ['BUCKET_NAME'],filename,ExtraArgs={"ContentType": "audio/mp3"})
    logger.debug("S3 UPLOAD RESPONSE IS--- %s" %s3upload_response)
    s3.put_object_acl(ACL='public-read', Bucket=os.environ['BUCKET_NAME'], Key= filename)
    
    location = s3.get_bucket_location(Bucket=os.environ['BUCKET_NAME'])
    logger.debug("Location response is -- %s" %location)
    region = location['LocationConstraint']
    
    if region is None:
    	url_begining = "https://s3.amazonaws.com/"
    else:
    	url = url_begining + str(os.environ['BUCKET_NAME']) + "/" + filename
    
    url = '{}/{}/{}'.format(s3.meta.endpoint_url, os.environ['BUCKET_NAME'], filename)
    
    #编码 URL
    encode_url = quote(url, safe='')
    logger.debug("ENCODED URL-- %s" %encode_url)
    
    # 从 http://twilio.com/user/account 获取这些凭证
    account_sid = os.environ['account_sid']
    auth_token = os.environ['auth_token']
    client = Client(account_sid, auth_token)
    
    # 使用 Twilio 进行电话呼叫
    call_response = client.api.account.calls.create(to=os.environ['ToPhoneNo'],  # 任意电话号码
    												from_=os.environ['FromPhoneNo'], # 必须是有效的 Twilio 号码
    												url="http://twimlets.com/message?Message%5B0%5D=" + encode_url + "&"
    												)
    												
    logger.debug("Call_response is-- %s" %call_response)

此 AWS Lambda 代码 zip 文件可从此处下载并用于 CloudFormation 堆栈部署。

解决方案验证

在接下来的示例语音中，我将演示在部署事件检测系统 (就根 API 活动进行通知) 并将其集成到文本到语音转换系统之后，每次在 AWS 账户上检测到根 API 时，我将收到电话呼叫报警。

由根触发的控制台登录警报电话呼叫示例：

立即收听 语音由 Amazon Polly 提供

然后，我使用根凭证创建 Amazon EBS 卷并获取另一个电话呼叫警报。

立即收听 语音由 Amazon Polly 提供

结论

在这篇帖子中，我演示了如何创建电话呼叫音频警报系统，该系统可集成到现有的警报和监视系统中。针对 AWS 账户中的关键事件，此框架在获取近乎实时的电话呼叫警报方面非常有用。

如需进一步了解，建议阅读以下内容：

• 使用 Amazon Polly 构建您自己的文本到语音应用程序
• 对 AWS 账户根用户活动进行监视和通知
• 在 AWS CloudTrail 中监视更改和自动启用日志记录

使用 Amazon Polly 针对 AWS 账户安全事件进行电话呼叫报警，首发于服务器安全维护工作室。

• 用户权限策略
• 访问控制策略
• 服务器安全策略
• 应用接入策略
• 网络分区策略
• 数据传输策略
• 数据存储策略
• 备份归档策略
• 日志记录策略
• 审计管理策略

……….

在实际的应用场景中，标准策略可能会因为业务的变化或管理方式的变化动态调整，如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致？如何帮助用户在云端更好的实现变更管理，安全分析甚至自动修正不合规的配置 ？这种场景下，可以考虑用AWS Config 服务来帮忙。

一、AWS config 是什么

AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config，还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南，并依据这些规则评估您记录的配置。

AWS Config的主要应用功能：

• 评估您 AWS 资源配置是否具备所需设置。
• 获得与您的 AWS 账户关联的受支持资源的当前配置快照。
• 检索您的账户中的一个或多个资源配置。
• 检索一个或多个资源的历史配置。
• 在资源被创建、修改或删除时接收通知。
• 查看不同资源之间的关系。例如，您可能想要找到使用特定安全组的所有资源

AWS Config工作原理

更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/

二、 AWS config 配置测试

为了更好了解AWS Config的工作过程，以下 将以AWS安全组的配置监控为例做一个简短测试 。

1. 测试场景：

• 一个为web服务器配置的安全组，该安全组策略只允许对Internet开放HTTP和HTTPS两个端口；
• 配置AWS Config 规则，当该安全组配置规则中添加了其他端口时，AWS Config 自动记录，并触发修复机制自动删除新加入的不合规的配置。

2. 配置过程

a. 权限准备。为成功配置AWS Config 规则，需要创建IAM 角色，授予 AWS Config 权限，使其可以访问Amazon S3 存储桶、Amazon SNS 主题，获取受支持的 AWS 资源的配置详细信息。IAM内置了一个AWSConfigRole的托管策略 。

新建一个IAM Role 命名为awsconfigrole, 可以直接附加该策略：

另外，测试过程中将使用lambda自动对安全组执行安全组操作，cloudwatch log操作，也需要建立好对应的IAM role并编辑策略赋予对应的权限,在测试中该IAM role为：awsoncifgec2security

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "logs:CreateLogGroup",

                "logs:CreateLogStream",

                "logs:PutLogEvents"

            ],

            "Resource": "arn:aws:logs:*:*:*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "config:PutEvaluations",

                "ec2:DescribeSecurityGroups",

                "ec2:AuthorizeSecurityGroupIngress",

                "ec2:RevokeSecurityGroupIngress"

            ],

            "Resource": "*"

        }

    ]

}

b. 配置AWS Config Setting。在AWS 控制台，打开 AWS Config ,具体过程可以参考：http://docs.aws.amazon.com/zh_cn/config/latest/developerguide/gs-console.html

在本测试过程中，我们选择资源类型为SecurityGroup:

在配置过程中，指定一个存储桶保存日志，并指定预先为AWS Config 的IAM Role ,当然也可以在这个步骤选择新建角色：

在上述页面中，可以选择是否通过SNS 启用通知将信息流式传输到 Amazon SNS 主题，发送配置历史记录传输、配置快照传输和合规性等通知。

在Resources页面中验证一下，评估的对象是否能正常的筛选出来，本例中我们是对测试的安全组进行查找：

c. AWS Config 规则配置。AWS Config提供一些内置的规则，也支持自定义规则创建。在前文中提及测试的背景中需要通过自动机制保证安全组规则符合设定的合规配置，我们将通过lambda完成该步骤。在创建规则的过程中，按向导设置规则名称，点击新建lambda功能按钮：

在lambda创建过程中，选择blank blueprint 并为函数指定runtime为python2.7 ，将准备好的代码保存在s3（可以在github中找到相关代码参考，比如https://github.com/awslabs/aws-config-rules ）并上传。

Lambda函数主要完成以下工作：

• lambda函数中按照要求只开启tcp 80 和tcp 443端口；
• 如果有其他端口添加到配置规则中将被删除，最终保证安全组的配置规则条目中只有tcp80和tcp443相关的配置；
• 相关的操作将记录在cloudwath logs中。

在创建过程中，为lambda指定对应的IAM Role.

lambda创建完成后，需要在AWS Config 规则页面中指定Lambda ARN,  配置触发器。本例中,当安全组配置发生变化时即触发对安全组的评估，也可以配置按照时间周期的评估对象。 另外，为了详细记录评估信息，为规则启用debug级别的记录。

AWS config  规则后，当前的安全组配置将自动被评估。

d. 验证。为触发AWS Config 对安全组的评估， 我们在对应的安全组规则中除tcp 80 和tpc443，额外新添加tcp445 端口。在cloudwathc logs中创建了logs group,可以进行相关日志查看：

在日志中可以清楚看到对安全组有revoking的行为，操作的端口正是额外添加的tcp445 ， 并且最终将安全组只开启tcp80 和tcp443 端口。

三、进一步讨论

在上述测试过程中，大致可以了解AWS Config的工作机制和配置流程，下面进一步对一些场景的应用场景做进一步说明。

资产发现

AWS Config 不仅会发现账户中的资源、记录其当前配置并捕获对这些配置所做的任何更改，Config 还会保留已删除资源的详细配置信息。所有资源及其配置属性的完全快照在您的账户中提供完整的资源库。

持续安全分析

AWS Config 提供的数据可使您持续监控您的资源配置情况，并评估这些配置是否具有潜在的安全弱点。对您的资源配置进行更改，将触发系统发送 Amazon Simple Notification Service (SNS) 通知，这些通知可发送给您的安全团队，以便他们查看通知并采取相应措施。发生潜在的安全事件后，您可以使用 Config 查看资源的配置历史记录并检查您的安全状况。

正如测试过程中展示，企业IT团队只需明确制定相关的策略，配置AWS Config规则，AWS Config提供了托管规则和自定义规则，能满足各种就能持续监控相关的安全标准是否合规。借助 AWS Config，利用 AWS Lambda 中的自定义规则将合规性要求编制成代码，这些代码会定义资源配置内部最佳实践和指南。您可以使用 Config 自动评估您的资源配置和资源更改，从而确保整个 AWS 基础设施实现持续合规性和自主监管。通过这个机制，为企业的安全自动化提供了一个可行选项。

变更管理

在创建、更新或删除资源时，AWS Config 会将这些配置更改流式传输到 Amazon Simple Notification Service (SNS)，如此便会收到所有配置更改通知。根据通知机制也可以考虑引入基于事件触发的机制，进一步集成各个管理环节。

在AWS Config按照既定规则完成评估后，可以在规则的详细信息中查看到具体的变更事件记录：

审计

AWS CloudTrail 将记录账户上的用户 API 活动，将保存有关 API 操作的完整详细信息，如发起人的身份、该 API 调用的时间、请求参数和 AWS 服务返 。AWS Config 与AWS CloudTrail 集成 ,回答“谁进行了修改此资源的 API 调用？”例如下图， 使用集成的 AWS CloudTrail 信息，可以发现是哪个用户错误配置了安全组。

综合上述讨论，企业内部资产管理团队可以清楚明确当前在AWS云端的数字资产，安全团队可以将严格制定的安全体系持续的在云端自动化运行，任何相关的变更和配置管理都能详尽的记录，方便后续的审计。

更多关于AWS Config的一些常见问题可参考：https://aws.amazon.com/cn/config/faq/

通过AWS Config 管理AWS服务配置，首发于服务器安全维护工作室。

一、转换现有系统并上传

这种方法是将VM上的系统用Amazon提供的命令行工具压缩成image并上传到S3，在注册成AMI。具体做法如下：

1. 安装ec2 ami tools 和ec2 api tools

通过以下命令安装ec2 ami tools

对于ec2 api tools，可以参考官方文档安装 『Setting Up the Amazon EC2 Command Line Tools』

2. 更改系统配置

首先是将ifcfg-eth0里的HWADDRESS去掉，并加上“NM_Controlled no”。然后是安装cloud-init（直接用yum安装）并根据官方修改配置。

3. 获得密钥并打包

在AWS网站上，account里的『Security Credentials』找到『X.509』，生成key.pem和cert.pem，然后用以下命令生成image文件并打包

其中是帐号的id，-d后面是指镜像放置的目录,-e代表忽略的目录——这个一定要加上，否则会进入死循环。

4. 上传

account里的『access key』找到找到access key id 和secret access key，然后用以下命令上传到S3

5. 注册AMI

这里，要用–region表明上传到哪个地区，ap-southeast-2是表示悉尼区。

二、现有系统新建系统并上传

这个做法的具体原理是：先在原有系统新建一个镜像文件，然后将其mount到某个目录，利用yum groupinstall Base将系统安装到该镜像文件，最后将文件打包并上传。 在镜像文件里安装系统的做法可以参考以下文章：『Create your own CentOS AMI Image (S3 Backed) 』、『Build your own Core CentOS 5.x AMI for Amazon EC2』 其中打包和上传的命令如下

上传完毕后，可以按照第一种方法注册AMI，也可以在AWS后台使用图形界面注册。

在AWS EC2中创建不含Marketplace code的CentOS6 AMI

参考资料：
https://www.caseylabs.com/remove-the-aws-marketplace-code-from-a-centos-ami/
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage_expand_partition.html

背景介绍：
在AWS EC2中，从Marketplace里面可以很方便的选择最新的CentOS6的官方Minimal版本的AMI，来创建Instance。
但是这里面却埋了一个大坑，那就是，所有基于Marketplace里面的AMI所创建的Instance，都会带有一个Marketplace code。
它会导致你无法通过为现有根分区所在的EBS Volume创建Snapshot和新的Volume的方式来对其扩容。
在Detach了现有的根分区所在的Volume后，将无法再次将其Attach到Instance当中，在Attach新的Volume时也会遇到相同的报错：

Client.OperationNotPermitted:
'vol-xxxxxxx' with Marketplace codes may not be attached as a secondary device.

这个Marketplace code，顾名思义，应该就是为了保护一些付费的AMI不被随意的克隆，但不知道为什么没有对费用为$0的CentOS6 AMI做单独的处理。
上面的限制，主要影响到的是，默认创建好的CentOS6 Instance的EBS Volume只有8G，即使在创建时指定了50G的EBS Volume，创建后的根分区空间也只有8G。这样的大小是无法满足线上需求的，只能对其进行扩容，而因为有上面的Marketplace code的限制，又使扩容变得很艰难。
还好最终我通过参考上面的两篇文章，从官方的CentOS6 AMI中移除了Marketplace code，并成功的对根分区进行了扩容并创建了相应的AMI。

具体步骤：
1. 从现有的CentOS6 AMI中移除Marketplace code
1.1 从AWS的Marketplace搜索CentOS6 AMI，并创建一个根分区所在的EBS Volume为8G（默认大小）的Instance；
1.2 在AWS EC2 web console中，再创建一个新的大小为8G的EBS Volume；
1.3 将新创建的EBS Volume Attach到Instance上，通常会默认识别为/dev/xvdj（HVM版本的AMI会识别为/dev/xvdf）；
1.4 通过SSH登陆到Instance，并通过dd克隆根分区所在的EBS Volume（HVM版本的AMI会将根目录所在的EBS Volume识别为/dev/xvda）：

dd bs=65536 if=/dev/xvde of=/dev/xvdj

1.5 当克隆完成以后，关闭Instance；
1.6 Detach现有根分区所在的EBS Volume;
1.7 Detach新创建的EBS Volume，并重新Attach到Instance，作为/dev/sda（HVM版本的AMI需要指定为/dev/sda1）；
1.8 启动Instance；
1.9 在确认Instance正常启动后，在EC2 web console中右键点击Instance，并选择Create Image，即可创建一个新的不含Marketplace code的CentOS6 AMI了，我一般将其命名为official_centos6_x86_64_minimal_ebs8g。

2. 将现有的AMI根分区所在的EBS Volume扩容为50G，并创建新的AMI official_centos6_x86_64_minimal_ebs50g
2.1 基于AMI official_centos6_x86_64_minimal_ebs8g创建一个Instance；
2.2 为Instance所在的EBS Volume创建一个Snapshot；
2.3 创建一个新的大小为50G的Volume，并包含刚刚创建的Snapshot；
2.4 将新创建的Volume Attach到Instance，作为第二块EBS Volume，默认会识别为/dev/xvdj（HVM版本的AMI会识别为/dev/xvdf）；
2.5 在Instance上对第二块EBS Volume进行扩容，详细步骤如下（HVM版本的AMI会将根目录所在的EBS Volume识别为/dev/xvda）：

[root@ip-172-17-4-12 ~]# parted /dev/xvdj
GNU Parted 2.1
Using /dev/xvdj
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdj: 104857600s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End        Size       Type     File system  Flags
 1      2048s  16777215s  16775168s  primary  ext4         boot

(parted) rm 1
(parted) mkpart primary 2048s 100%
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdj: 104857600s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End         Size        Type     File system  Flags
 1      2048s  104857599s  104855552s  primary  ext4

(parted) set 1 boot on
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdj: 104857600s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End         Size        Type     File system  Flags
1      2048s  104857599s  104855552s  primary  ext4         boot

(parted) quit
Information: You may need to update /etc/fstab.

[root@ip-172-17-4-12 ~]# e2fsck -f /dev/xvdj1
e2fsck 1.41.12 (17-May-2010)
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? yes

/dev/xvdj1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/xvdj1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/xvdj1: 18425/524288 files (0.2% non-contiguous), 243772/2096896 blocks

[root@ip-172-17-4-12 ~]# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvde    202:0    0   8G  0 disk
└─xvde1 202:1    0   8G  0 part /
xvdj    202:80   0  50G  0 disk
└─xvdj1 202:     0  50G  0 part

[root@ip-172-17-4-12 ~]# resize2fs /dev/xvdj1
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/xvdj1 to 13106944 (4k) blocks.
The filesystem on /dev/xvdj1 is now 13106944 blocks long.

2.6 关闭Instance；
2.7 Detach现有根分区所在的EBS Volume;
2.8 Detach扩容后的第二块EBS Volume，并重新Attach到Instance，作为/dev/sda（HVM版本的AMI需要指定为/dev/sda1）；
2.9 启动Instance；
2.10 在确认Instance正常启动后，在EC2 web console中右键点击Instance，并选择Create Image，即可创建一个新的根分区大小为50G的CentOS6 AMI了，我一般将其命名为official_centos6_x86_64_minimal_ebs50g。

PS: 自己制作的镜像，如果要支持创建时自定义指定SSH Public Key，需要确保/etc/rc.local中包含以下代码，同时将镜像中的/root/.ssh/authorized_keys文件删除。

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

# set a random pass on first boot
if [ -f /root/firstrun ]; then
  dd if=/dev/urandom count=50|md5sum|passwd --stdin root
  passwd -l root
  rm /root/firstrun
fi

if [ ! -d /root/.ssh ]; then
  mkdir -m 0700 -p /root/.ssh
  restorecon /root/.ssh
fi

# Get the root ssh key setup
ReTry=0
while [ ! -f /root/.ssh/authorized_keys ] && [ $ReTry -lt 10 ]; do
  sleep 2
  curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /root/.ssh/pubkey
  if [ 0 -eq 0 ]; then
    mv /root/.ssh/pubkey /root/.ssh/authorized_keys
  fi
  ReTry=$[Retry+1]
done
chmod 600 /root/.ssh/authorized_keys && restorecon /root/.ssh/authorized_keys

制作自己的AMI

亚马逊AMI market上提供的AMI有的含有Market Code(不允许将跟分区作为第二分区挂载到别的实例上进去修改根分区内容），有的AMI不支持特定实例类型（例如CentOS.org提供的AMI就不支持c3系列）。因此有必要自己做几个AMI。制作方法和步骤如下：
（1）自己在合适的位置安装一个精简版的CentOS，尽量最简化安装，因为一会要把系统文件内容全部同步到亚马逊上去。还可以直接将虚拟机import进AWS。安装的时候使用/dev/sda1 跟分区，/dev/sda1 swap分区，不要用LVM。例子里我们是创建1GB的vmware磁盘，不要使用动态扩展，尽量使用一次性分配。然后分区/dev/sda1 768M,剩下的MB全部给swap,此处大小要是2的n次方，否则会出现partition doesn’t end with disk boundry类似的警告提示。
（2）第二部将系统内容弄到AWS上去，此处提供两个方案:
首先在一台配置到aws tools的机器（推荐Amazon AMI创建的的EC2），创建一块25GB的EBS volume,并attach，然后格式化分区，17GB/, 8GB swap，精确到MB，然后

mkfs.ext4 /dev/xvdj1;
e2label /dev/xvdj1 /  (打上标签）；
mkswap -L swap /dev/xvdj2(也打上标签），
#然后挂载
mount /dev/xvdj1 /ebs（自己创建一个挂载点）

使用rsync将刚才安装的虚拟机文件系统同步到上述挂载点中

rsync -avx -e "ssh -i xxxxx.pem" /* user@ip:/ebs/

使用ec2-import-volume命令将虚拟机磁盘导入到AWS的一块EBS磁盘中。命令如下：

ec2-import-volume centos6.5.disk -f raw -b <your_s3_bucket_name> \
 --region ap-southeast-1 -O <access_key_id> -W <secret_access_key> \
 -o <access_key_id> -w <secret_access_key>

-f是指定格式：kvm、xen的是raw, vmware的是vmdk,hyper-v的是vhd（vhdx格式好想目前还不支持，需要转成vhd格式），-b是指定与你导入地区一致的s3 bucket，因为此过程是通过S3中转的。然后你会得到一块磁盘，attach到上述Amazon AMI的EC2上，然后把内容复制出来。
（3）进入到/ebs中修改你刚才同步过来的文件系统
检查/etc/grub.conf，主要是默认会采用uuid来指定分区，但是复制的vm uuid是不一样的，因此要改成LABEL形式，如下：

default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32-358.el6.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-358.el6.x86_64 ro root=LABEL=/ console=ttyS0
initrd /boot/initramfs-2.6.32-358.el6.x86_64.img

修改/etc/sysconfig/network-scripts/ifcfg-eth0（注意安装虚拟机得时候只要一个网卡),修改成如下

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

修改/etc/fatab，改成用LABEL挂载，如下：（none开头的保持默认）

LABEL=/ / ext4 defaults 1 1
LABEL=swap swap swap defaults 0 0

( 4）将改好的EBS磁盘做成snapshot快照，并获取snapshot ID备用
（5）在上述工作机上用ec2-register命令注册AMI

ec2-register -n "CentOS6.4" -d "CentOS6.4" -a x86_64 -K pk-xxxxxx.pem \
 -C cert-mod.pem --root-device-name /dev/sda1 \
 -b /dev/sda=snap-a40edf49:25:true --kernel aki-503e7402 \
 --region ap-southeast-1

这一步骤需要你账号的X.509 Certificates密钥对（在security credential里面找），还需要kernel id,具体该使用哪个aki,详见这个官方文档链接
AmazonKernelImageIDs
（6）试着基于自己创建的AMI创建一个实例，然后进去自定义一下，再在实例上右键注册成自己个性化的AMI(我一般会装上CloudWatch然后写个README说这个AMI是我做的cloudwatch别删除）
至此完毕

将虚拟机导入到AWS

借助ec2-import-instance我们可以将我们的虚拟机导入到AWS中的EC2实例里。

~$ ec2-import-instance centos6.4-vm01.disk -f raw -p Linux -t m3.large \
 -a x86_64 -b <your_s3_bucket> --region ap-southeast-1 -O <access_key_id> \
 -W <secret_access_key> -o <access_key_id> -w <secret_access_key>

(参数为多个字母的都是双-，不知为啥我的总显示为多-,不管有几个-。例如–region参数。请注意，后同)
然后可以用ec2-describe-conversion-tasks命令查看导入过程。ec2-cancel-conversion-task命令取消导入任务。

~$ ec2-describe-conversion-tasks --region ap-southeast-1 import-i-ffm0xv71 -O xxxx -W

xxxxx(import-i-ffm0xv71这个是ec2-import-instance任务的任务ID，在命令输出结果中有)
如果都顺利的话，你能到指定的region得到一台EC2实例，默认是关机状态。
在这个过程中需要注意如下事项：
导入虚拟机的时候，虚拟机只支持一个DHCP的网卡，多网卡的删掉，光驱可以删掉（至少不能让他挂载这ISO的状态导入），如果有多个磁盘，此命令只能导入跟分区所在的虚拟磁盘（注意不是指根分区所在的分区）其他的磁盘用下面介绍的ec2-import-volume导入
导入的虚拟机配置类型是有限制的（Linux虚拟机是有限制的，Windows虚拟机时无限制）
We support importing Windows instances into any instance type. Linux instances can be imported into the following instance types：m3.xlarge、m3.2xlarge、hi1.4xlarge、hs1.8xlarge、cc1.4xlarge、cg1.4xlarge、cc2.8xlarge、cr1.8xlarge
如果将导入的虚拟机右键注册成AMI（如果你使用的默认的AKI)将会导致你的AMI只能创建指定类型的EC2实例，需要选择合适的AKI,见上一篇文档的分享链接。

用ec2-import-volume将虚拟机磁盘导入AWS EBS

~$ ec2-import-volume centos6.4.disk -f raw -b <your-s3-bucket> \
 --region ap-southeast-1 -O xxxx -W xxxxxxxx -o xxxx -w xxxxxx

使用ec2-describe-conversion-tasks查看导入的进度，完成之后你会得到一个状态为Available的EBS Volume。

AWS折腾记——为EC2制作镜像，首发于服务器安全维护工作室。

1 阿里云官方Docker Hub地址

http://dev.aliyun.com/search.html

2 新用户

第一次使用阿里云Docker服务，用户需要先注册成为开发者，步骤如下：

打开上面的阿里云Docker Hub，未登陆的，先使用云账号登录，登录/注册在左上角； 点击右上角“管理中心”，如下图：

对新用户会弹出去注册开发者的页面：

注册成功之后，点击“进入管理控制台”，下次进入也可以在Docker Hub页面，点击右上角“管理中心”进入。界面如下：

选择左侧的“Docker服务”下面的“镜像管理”标签，新用户会提示设置自己的镜像仓库“命名空间”和密码。命名空间是私人镜像的地址前缀。完成设置之后，可以开始使用阿里云Docker仓库。

3 使用 Docker

3.1 docker 仓库地址

阿里云官方docker仓库地址为：

registry.aliyuncs.com（公网)

在GPU物理机上，对应替换为内网地址：

registry-internal.aliyuncs.com（内网）

3.2 运行 Hello World

（GPU物理机预装CentOS 7系统，以下操作仅以CentOS 7为例，且使用root用户） 首先检查机器上安装的docker服务状态：

# docker info

正常会显示当前存储空间等信息。如果出错，请先尝试重启docker服务：

# systemctl restart docker

下一步，使用阿里云账号和之前设定的docker仓库密码，登录阿里云docker仓库：

# docker login registry-internal.aliyuncs.com

运行 Hello World：

# docker run registry-internal.aliyuncs.com/alicloudhpc/hello-world

如果一切正常，说明机器的docker服务运行正常。

3.3 使用深度学习和HPC工具集

工具集的发布地址是：

http://dev.aliyun.com/detail.html?repoId=2

列出了包含的软件工具和简介。

登录之后，可以下载toolkit的镜像到本地：

# docker pull registry-internal.aliyuncs.com/alicloudhpc/toolkit

重命名一个短名称：

# docker tag registry-internal.aliyuncs.com/alicloudhpc/toolkit toolkit

因为需要在docker容器中使用gpu设备，启动docker容器需要设定额外参数。推荐将如下内容保存到一个shell脚本（比如run-toolkit.sh），方便以后运行：

#!/bin/bash
DOCKER_BIN="/usr/bin/docker"
INTERACT="-ti"
#INTERACT="-d"
DATA_VOLUME="/disk1"
DATA_MOUNT_POINT="/disk1"
MEM_LIMIT=96g

set -e
if [ $# -lt 2 ]; then
    echo "Usage: $0 image command"
    exit -1
else
    IMAGE=$1
    shift 1
    CMD=$@
fi

devices=$(ls -1 /dev | grep nvidia)
dev_param=""
for d in $devices; do
    dev_param="$dev_param --device=/dev/$d"
done

time_param='-v /etc/localtime:/etc/localtime:ro'

if [ ! -z "$CUDA_VISIBLE_DEVICES" ]; then
    dev_env="-e CUDA_VISIBLE_DEVICES=$CUDA_VISIBLE_DEVICES"
else
    dev_env=""
fi

exec $DOCKER_BIN run \
        "$INTERACT" \
        -P \
        $dev_env \
        $dev_param \
        $time_param \
        -m $MEM_LIMIT \
        -v $DATA_VOLUME:$DATA_MOUNT_POINT \
        "$IMAGE" \
        $CMD

运行脚本，启动toolkit：

# chmod +x run-toolkit.sh
# ./run-toolkit.sh  toolkit  /bin/bash

成功运行之后，已经进入交互式的docker容器（理解为一个与host隔离的运行环境）中，物理机上的 /disk1 磁盘映射到容器内的 /disk1 文件夹，建议数据只存储到 /disk1 下（如果容器销毁，其他数据不会保留）。

检查GPU工作正常：

# /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery

检查通过以后，您可以像普通终端一样，运行软件。

3.4 重新进入

在交互式docker容器中，如果您运行 exit，退出docker容器之后，该容器即停止。如果您在容器中修改了 /disk1 以外的内容（比如安装软件），下次还需要继续使用，则不应该运行 run-toolkit.sh 新建容器，而是重启原先的，操作如下：

查询已经停止的容器id：

# docker ps -a

返回结果中，复制下需要重启的容器的 container_id

重启容器：

# docker start container_id

成功则返回一串重复的id

重新进入交互式docker容器：

# docker attatch container_id

4. 使用进阶

4.1 获得更新

如果toolkit发布新的版本，可以重新pull获得更新：

# docker pull registry-internal.aliyuncs.com/alicloudhpc/toolkit

重命名一个短名称：

# docker tag registry-internal.aliyuncs.com/alicloudhpc/toolkit toolkit

4.2 创建私有镜像

访问阿里云docker控制台：

http://console.d.aliyun.com/index2.html/?#/docker/image/list

可以创建自己的私有镜像（选择本地仓库）。

使用和创建本地镜像的方法，可以参考docker官方文档相关部分：

http://docs.docker.com/userguide/dockerimages

另外有一份中文教程：http://www.docker.org.cn/book/docker.html （有些过时） 注意内网环境下，添加或者替换docker仓库的域名。

本地镜像创建完成后，通过docker push上传到阿里云docker仓库：

# docker tag some-image registry-internal.aliyuncs.com/YOUR_NAMESPCE/YOUR_REPO
# docker push registry-internal.aliyuncs.com/YOUR_NAMESPCE/YOUR_REPO

阿里云Docker 镜像服务，首发于服务器安全维护工作室。

SRE是Site Reliability Engineer的简称，从名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整个Google服务的稳定性。SRE不接触底层硬件如服务器，这也是高逼格的由来.

Google 数据中心的硬件层面的维护工作是交给technician来做的，technician一般不需要有大学学历。

SWE是SoftWare Egineer的简称，即软件工程师（负责软件服务的开发、测试、发布）。SWE更新的程序代码（下文称为server），只有在SRE同意后才能上线发布。因此，SRE在Google工程师团队中地位非常高！我们下面将分别介绍。

SRE 职责

SRE在Google不负责某个服务的上线、部署，SRE主要是保障服务的可靠性和性能，同时负责数据中心资源分配，为重要服务预留资源。如上文所述，和SRE相对应的是SWE（软件开发工程师），负责具体的开发工作。

举个例子，我之前在Google的互联网广告部门，我们team负责的server是收集用户数据用于广告精准投放，这个server的开发、测试、上线部署等工作，都是由SWE来完成。

SRE不负责server的具体实现，SRE主要负责在server出现宕机等紧急事故时，做出快速响应，尽快恢复server，减少服务掉线带来的损失。

备注：这里的server是指服务器端程序，而不是物理服务器。在Google，SWE和SRE都无权接触物理服务器。

SRE 要求

因为SRE的职责是保障服务的稳定和性能，所以在SRE接手某个server之前，对server的性能和稳定性都有一定的要求，比如server出现报警的次数不能超过一定的频率，server对CPU、内存的消耗不能超过预设的指标。

只有server完全满足SRE的要求以后，SRE才会接手这个server：

当server出现问题时，SRE会先紧急修复，恢复服务，然后SRE会和SWE沟通，最终SWE来彻底修复server的bug。

同时，对server的重大更新，SWE都要提前通知SRE，做好各种准备工作，才能发布新版server：

为了能让SRE能接手server，SWE要根据SRE的要求，对server做大量的调优。首先SRE会给出各种性能指标，比如，服务响应延迟、 资源使用量等等，再者SRE会要求SWE给出一些server评测结果，诸如压力测试结果、端到端测试结果等等，同时，SRE也会帮助SWE做一些性能问 题排查。

所以SRE在Google地位很高，SWE为了让server成功上线，都想法跟SRE保持好关系。

我举个具体的例子来说明，在Google，SWE是如何跟SRE配合工作来上线server的。

我们team对所负责的server进行了代码重构，重构之后，要经过SRE同意，才能够上线重构后的server。

为此，我们team的SWE要向SRE证明，重构后的server对资源的开销没有增加，即CPU、内存、硬盘、带宽消耗没有增加，重构后的server性能没有降低，即端到端服务响应延迟、QPS、对压力测试的响应等这些性能指标没有降低。

当时对server代码重构之后，server有个性能指标一直达不到SRE的要求。这个指标是contention，也就是多线程情况下，对竞争资源的等待延迟。重构server之后，contention这项指标变得很高，说明多线程情况下，对竞争资源的等待变长。

我们排查很久找不到具体原因，因为SWE没有在代码中显式使用很多mutex，然后请SRE出面帮忙。SRE使用Google内部的图形化profiling工具，cpprof，帮我们查找原因。

找到两个方面的原因：

• tc_malloc在多线程情况下频繁请求内存，造成contention变高；
• 大量使用hashmap，hashmap没有预先分配足够内存空间，造成对底层tc_malloc调用过多。

SRE 工作内容

简而言之，Google的SRE不是做底层硬件维护，而是负责Google各种服务的性能和稳定性。换句话说，Google的SRE保证软件层面的性能和稳定性，包括软件基础构架和应用服务。

SRE需要对Google内部各种软件基础构架(Infrastructure)非常了解，而且SRE一般具有很强的排查问题、debug、快速恢复server的能力。

我列举一些常见的Google软件基础构架的例子：

• Borg：分布式任务管理系统，
• Borgmon：强大的监控报警系统；
• BigTable：分布式Key/Value存储系统；
• Google File System：分布式文件系统；
• PubSub：分布式消息队列系统；
• MapReduce：分布式大数据批处理系统；
• F1：分布式数据库；
• ECatcher：日志收集检索系统；
• Stubby：Google的RPC实现；
• Proto Buffer：数据序列化存储协议以及RPC协议；
• Chubby：提供类似Zookeeper的服务。
• Google还有更多的软件基础构架系统：Megastore、Spanner、Mustang等等，我没有用过，所以不熟悉。

运维未来发展方向

我个人觉得，在云计算时代，运维工程师会慢慢向Google的SRE这种角色发展，远离底层硬件，更多靠近软件基础架构层面，帮助企业客户打造强大的软件基础构架。

企业客户有了强大的软件基础构架以后，能够更好应对业务的复杂多变的需求，帮助企业客户快速发展业务。

另外我个人观点，为什么Google的产品给人感觉技术含量高？

并不见得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程师能力强多少，主要是因为Google的软件基础构架（详见上文）非常强大，有了很强大的基础构架，再做出强大的产品就很方便了。

Google内部各种软件基础构架，基本上满足了各种常见分布式功能需求，极大地方便了SWE做业务开发。换句话说，在Google做开发，SWE基本上是专注业务逻辑，应用服务系统(server)的性能主要由底层软件基础构架来保证。

谷歌是这样做运维的，首发于服务器安全维护工作室。

server {
listen       80 default_server;
server_name  _;
location / {
proxy_pass http://xxx.oss-cn-qingdao-internal.aliyuncs.com/;
proxy_set_header   Referer             http://www.test.com;
}
}

如何限制通过固定的IP访问阿里云OSS的文件，首发于服务器安全维护工作室。

 环境两台阿里云ECS服务器 ，一台公网，一台内网。内网安装nginx，希望访问公网服务器的时候，能够访问到内网的nginx站点。
 
 内网服务器操作过程如下：

首先安装nginx和启动

测试nginx安装正常，可以访问。

公网服务器操作如下：

 首先修改内核参数，开启ip转发

配置iptables，将访问公网服务器80端口的请求，转发到内网服务器的80

这时候我们访问公网服务器IP测试一下，同时抓包看转发后的数据包情况：

这样原地址是访客的公网IP，目标是内网服务器的内网地址，这样也没办法双向通讯啊，所以，需要让这个数据包的原地址，也变成内网地址，这样才能和内网服务器建立通讯。
修改原地址就是SNAT
我们继续在公网服务器配置：

抓包分析：

访客本地公网->公网服务器公网IP
修改目标地址
公网服务器内网IP->内网服务器IP
修改原地址
内网服务器IP->公网服务器内网IP
公网服务器公网IP->访客本地公网

完成通讯，试试看。

阿里云服务器如何配置端口映射Dnat教程，首发于服务器安全维护工作室。

1. 搭建系统之前

这个系统是用来做电子商务、论坛、企业网站等等，接着要考虑一下网站上线以后的高峰期的访问量是多少。最重要的是，我能承受系统或者服务器停止服务的时间是多长时间。

2. 选择专业团队

自己公司有资源的话就利用现有资源，当自己公司没有专业的系统工程师的时候，就要考虑外包给专业的团队。您可以先找几家系统集成商或者服务器代维公司要报价进行一个比较。你可能会了解到系统构筑的费用构造，并且跟他们的沟通会让你对系统的了解加深。

3. 系统搭建

根据你提供的需求(PV/分，系统的可用性，数据的完全性等等)，系统集成商或者服务器代维公司会开始进行搭建。

4. 测试

你需要对搭建完的系统进行2个方面的测试。第1个是功能方面的测试，第2个是性能方面的测试。比如；

• 功能方面：FTP访问，root禁止登录，数据库主从切换，故障恢复等等
• 性能方面：用Jmeter工具等对系统进行压力测试，查看整个系统的承载量。

你网站或者应用的访问量大的时候，这个性能测试是必须做的。对今后的系统扩张及每年的系统预算相关的重要部分。

5. 上线

当功能测试和性能测试都没有问题的话，恭喜你！系统可以上线了。

6. 运维

运维也可以分为2种，一个是攻，一个是守。

运维之攻
监视系统的CPU、内存、磁盘等的使用情况，并且根据业务量的增加，及时的增加服务器或者磁盘等资源。

运维之守
守之重，可以说是备份。比如服务器重要配置文件、应用程序、数据库的数据等等。

当你的系统测底崩溃以后，你想尽快恢复系统的心情是理解的，但是那是有准备的情况下。

小结

个人认为系统集成商的技术固然重要，但是更重要的是这个团队有一个站在客户角度思考问题的态度。

IT行业不仅仅是提供技术，而更应该提供良好服务的服务行业。

浅谈系统搭建外包的流程及建议，首发于服务器安全维护工作室。

centos用户登录到Amazon EC2服务器以后，sudo到root用户。

在CentOS7 AMI执行yum install mysql-server命令会发现无法安装mysql server。

# sudo su -
# yum install mysql-server
Loaded plugins: fastestmirror
base                                                     | 3.6 kB     00:00
epel/x86_64/metalink                                     | 5.5 kB     00:00
epel                                                     | 4.4 kB     00:00
extras                                                   | 3.4 kB     00:00
rpmforge                                                 | 1.9 kB     00:00
updates                                                  | 3.4 kB     00:00
epel/x86_64/primary_db                                     | 3.8 MB   00:00
(1/2): epel/x86_64/updateinfo                              | 230 kB   00:00
(2/2): epel/x86_64/pkgtags                                 | 1.3 MB   00:00
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: s3-mirror-ap-northeast-1.fedoraproject.org
 * extras: www.ftp.ne.jp
 * rpmforge: ftp.riken.jp
 * updates: www.ftp.ne.jp
No package mysql-server available.
Error: Nothing to do

因为，CentOS7的默认数据库是MariaDB。

1, 配置MySQL5.6的Repository

访问http://www.mysql.com/downloads/以后，点击「Downloads」→「Yum Repository」。

选择Red Hat Enterprise Linux 7 / Oracle Linux 7 (Architecture Independent), RPM Package的「Download」

在这里会显示登录Oracle的页面，但是不必登录，拷贝No thanks, just start my download.的链接就可以。

拷贝的链接是：http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm

配置MySQL5.6的yum源。

# rpm -ivh http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm
Retrieving http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:mysql-community-release-el7-5    ################################# [100%]

确认MySQL5.6yum源存在。

# yum repolist
Loaded plugins: fastestmirror
mysql-connectors-community                               | 2.5 kB     00:00
mysql-tools-community                                    | 2.5 kB     00:00
mysql56-community                                        | 2.5 kB     00:00
(1/3): mysql-connectors-community/x86_64/primary_db        | 7.0 kB   00:00
(2/3): mysql-tools-community/x86_64/primary_db             |  11 kB   00:00
(3/3): mysql56-community/x86_64/primary_db                 |  59 kB   00:00
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.jaist.ac.jp
 * extras: www.ftp.ne.jp
 * rpmforge: ftp.riken.jp
 * updates: www.ftp.ne.jp
repo id                           repo name                               status
base/7/x86_64                     CentOS-7 - Base                         8,465
epel/x86_64                       Extra Packages for Enterprise Linux 7 - 6,912
extras/7/x86_64                   CentOS-7 - Extras                         102
mysql-connectors-community/x86_64 MySQL Connectors Community                 12
mysql-tools-community/x86_64      MySQL Tools Community                      12
mysql56-community/x86_64          MySQL 5.6 Community Server                 94
rpmforge                          RHEL 7 - RPMforge.net - dag               245
updates/7/x86_64                  CentOS-7 - Updates                      1,497
repolist: 17,339

2, 安装MySQL

# yum install mysql-server

# mysql --version
mysql  Ver 14.14 Distrib 5.6.22, for Linux (x86_64) using  EditLine wrapper

成功的在Amazon CentOS7 AMI上安装了MySQL5.6.22。

小结

CentOS7，好像有不少改变呀。好像service命令变为systemctl命令了。

# service mysqld stop
Redirecting to /bin/systemctl stop  mysqld.service

Amazon CentOS7 AMI安装MySQL5.6教程，首发于服务器安全维护工作室。

服务器代维就是个人站长或企业将本身的服务器委托专业的公司管理与维护，以达到降低成本的目的。

众所周知，无论个人还是企业，想运维好服务器就需要投入大量的精力以及人力物力，服务器外包已经成为很多站长降低成本的一种重要的手段。

目前从实践来看，需要服务器代维群体大体分两类：

• 一类是自己不想承担或承担不起一个可以做到7×24小时服务器运维团队的成本
• 二类是认为专业人做专业事，将精力、能力聚集到核心业务发展之上

服务器代维会为企业带来什么

1. 大大提高企业服务器运维速度。不仅节省了传统的各环节间转换的时间，还为企业节省了培训员工熟悉业务的时间。
2. 降低企业服务器管理成本。首先是从时间的节约带来的费用的降低，另一方面则是通过减少不必要的人力物力给企业带来更大的益处，相信这一点，没用过服务器代维的企业体会不到的。
3. 提高企业服务器运维质量。由于紧密合作的关系以及长期合作的时间，使得运维方对企业的服务器能进行十分深入、细致的理解，服务器运维过程中在切合企业实际业务运作等方面会有不可比拟的体现。当然，服务器代维也有其天生的缺陷，比如：
   • 提供高品质的代维企业难找，即使有，与企业建立互信也成为一个难点。
   • 企业的服务器风险将集中在代维商的责任心和水平之上。这一根本性的问题，也是导致很多企业决策者虽然明白服务器代维的好处，但是却始终犹豫的主要原因。

小结

因此，本人以多年的服务器运维实践经验认为，企业实行服务器运维外包的可行方法，就是：

企业让代维商从小的、短期合作开始切入，相互磨合、建立了信任的基础、 企业对运维公司的能力也有了充分认识后，再尝试长期的服务合作。此时，运维公司就不再是一个简单的服务提供者，也可以参与企业的决策环节，提供更专业的意见。

简言之，服务器代维就是企业用一个网管的工资雇用了一个专业的运维团队为其开展CTO的工作。形式不同，目的一致，效果却更突出。

信息化管理的时代，服务器代维更符合企业的实际发展需要，代维优势决定了其未来将会得到业内人士更多的关注与研究。

运维一二三工作室，你最值得信赖的朋友！

服务器代维是救命草还是鸡肋，首发于服务器安全维护工作室。