使用AWS Elastic Beanstalk实现环境自动化部署

2 年 ago
新, 韵
4 minutes

弹性 Beanstalk 可自动设置服务的服务器环境，并根据指定条件进行自动扩展设置。由于信息还很少，因此为了在实际运营中使用，我进行了配置，所以应该比其他任何日文文章都更详细。实际上，感觉有一种非常摸索的感觉。

能 & 不能

为了避免阅读时的绝望，我提前写下来。

可以的！

    • サーバの応答が遅くなったり、CPU負荷が上がったりした時に自動でEC2インスタンスをロードバランサ下に紐づけて登録済みファイルを配置してくれる

 

    • 自動でデプロイされたサーバには指定したユーザを作成して、RSAログインできるようにして、yumで指定したサービスをインストールして、各種設定ファイルも独自のものに置き換えて再起動させちゃう

 

    アップデート時にはダウンタイムが発生しないようAct-Sby構成を自動で作って切り替え

不，我们不能…

需要手动进行设置。手动操作可以搞定。

    あらかじめEBで指定できる項目を超えた制御

将除了HTTP、HTTPS之外的项目添加到负载均衡器中（如果更改自动生成的ELB配置则可能实现 => 如果终止则配置会消失）
将自动启动的实例与指定的弹性IP关联（必须使用命令行接口才能实现，但是如何确定自动启动的实例会比较困难）
重复使用原先生成的实例和资源 => 总之会创建新的实例。旧的则会被删除。秉承”来者不拒，去者不追”的精神。

开始时，由于不知道能做到什么和不能做到什么，所以花了相当长的时间来调查了解到这一点。但是无论如何，我们终于可以做到了！

应用程序的建设

登陆AWS管理控制台，点击位于中央下方的Elastic Beanstalk，通过应用程序概念来管理配置设置。

AWS Management Console TOP

点击右上方的“创建应用程序”按钮，以设置Elastic Beanstalk的顶部和详细信息。
继续进行各种设置。
根据查询结果，有很多使用命令行工具进行设置的方法，但在这里我们将使用AWS Management Console。
尽管很容易不小心点击中央的“立即启动”按钮，但使用该按钮会导致所有设置都以默认配置启动，这会带来困扰。

Elastic Beanstalk

应用程序概要设置。

スクリーンショット 2014-04-20 18.10.18.png

环境设置

在这个阶段，已经有一个空的应用程序了。所以即使中途中断也没关系。
接下来，我们会为这个应用程序添加概念上的环境。例如开发用、正式发布用等不同分支。

スクリーンショット 2014-04-20 19.20.35.png
スクリーンショット 2014-04-20 18.12.01.png

增加资源

スクリーンショット 2014-04-21 12.23.47.png

EC2实例设置

スクリーンショット 2014-04-21 12.25.32.png
スクリーンショット 2014-04-21 12.36.50.png

应用程序健康检查URL是负载均衡器用于健康检查的URL。
在这种情况下，如果已经建立了网站且通过了健康检查，可以输入URL，但在首次建立时，建议先不输入（默认为：http://环境名称.elasticbeanstalk.com），而是使用这个别名来进行健康检查。
如果健康检查不通过，就无法更改详细设置，这是我曾经遇到的问题…

另一个让人担忧的是启用滚动更新。当我进行了一番调查后发现了一些信息。

如果启用Elastic Beanstalk环境的滚动更新，您可以设置环境中的请求处理能力和更新所需的时间之间的平衡。例如，在开发环境中，会同时更新所有实例，但在生产环境中会逐个更新一部分实例。

因为嘛，好心跳噗通噗通地呢。
在更新期间，能否顺利地操作到 LB 呢，好厉害呢！之后再报告一下操作效果。
因为可以之后关掉，所以暂时先检查一下再继续进行吧。

如果将其作为预留实例进行处理，则需要与购买的可用区匹配，因此必须在启动后对其进行更改才可以。因为要考虑费用（大约$0.06），所以先用micro实例启动，之后再进行更改试试看。

确认设置的内容

スクリーンショット 2014-04-21 12.59.18.png
スクリーンショット 2014-04-21 13.03.35.png

更多设定

スクリーンショット 2014-04-21 15.41.56.png

擴展尺度

スクリーンショット 2014-04-21 14.14.42.png

如果您有保留实例，并且想要将可用区固定，请将可用区设置为”Any 1″，然后从自定义可用区中选择所购买的区域。实例类型的更改请在“Instances”部分进行。保存后，EC2将重新构建。

需同时考虑扩展冷却时间和下一步的扩展触发条件。

尽早进行扩展（有余地），慢慢进行Scaling cooldown 是AutoScaling的标准态度。
参考：Netflix的扩展 – 自动化篇
这是一篇非常珍贵的经验文章。让我们一读吧。

默认触发器设置为NetworkOut（以什么情况为基准呢？）
如果是Web服务的话，似乎Latency、CPU利用率和请求次数等比较方便使用。

スクリーンショット 2014-04-21 16.33.02.png

有关每个设置值的详细信息，请参考以下内容
选项的值

如果终止环境，所有之前的设置都会消失。对于修复后的环境设置，从动作中保存配置会让人感到安心。

设置得更多。

还不够！我想要改变PHP的设置和Web服务器，什么都还不够！
所以为了更细致地配置，我尝试使用eb命令进行快速部署。
这需要进行繁琐的配置文件编写，非常麻烦。
可能EB在这一点上非常重要。

在部署应用程序时，有时候需要对应用程序所依赖的软件进行定制和配置。这些文件包括应用程序所需的依赖关系（例如从 yum 仓库添加的额外包）以及用于覆盖 AWS Elastic Beanstalk 的默认特定配置的 httpd.conf 替代配置文件等。此外，有时也需要对作为 AWS Elastic Beanstalk 环境一部分的环境资源进行定制（例如 SQS 队列、ElastiCache 集群）。例如，可以添加针对 Amazon SQS 队列和队列深度的警报，或者添加 Amazon ElastiCache 集群。

通过将配置文件与源代码捆绑在一起，您可以在部署应用程序版本时轻松自定义环境。与自定义独立 AMI 相比，使用配置文件来自定义实例软件更具优势，因为您无需维护 AMI 的集合。

太棒了！！！ le!)

参考：公式文件

首先，我们会准备工作环境。

安装 eb 命令

[AWS专家系列] AWS弹性Beanstalk

在解压后的目录中，根据各个操作系统的要求为eb命令设定路径。我们的OS X系统应按以下方式处理。


$ echo 'export PATH="$HOME/.AWS-ElasticBeanstalk-CLI-2.2/eb/macosx/python2.7:$PATH"' >> .bashrc
$ source .bashrc
$ eb --help

eb命令是类似于将git包装起来的结构（git是必需的）。
因此，在操作（源代码）目录中，需要预先进行git init。
在操作目录的根目录下继续以下步骤。
如果应用程序名称和环境名称匹配，它会自动收集并检索已经存在的环境信息，作为UI端创建的。


$ eb init
Enter your AWS Access Key ID: [IAMユーザのAccess Key]
Enter your AWS Secret Access Key: [IAMユーザのSecret Access Key]
1) US East (Virginia)
2) US West (Oregon)
3) US West (North California)
4) EU West (Ireland)
5) Asia Pacific (Singapore)
6) Asia Pacific (Tokyo)
7) Asia Pacific (Sydney)
8) South America (Sao Paulo)
Select (1 to 8): [使用するリージョン]
Enter an AWS Elastic Beanstalk application name (auto-generated value is "repo.hihin.git"): [上で作っておいたapplication name]
Enter an AWS Elastic Beanstalk environment name (auto-generated value is "hihinjp-env"): [環境名（開発とか本番）※.(ドット)を使用するとドメイン周りでトラブる可能性があるので注意]

Select an environment tier.
Available environment tiers are:
1) WebServer::Standard::1.0
2) Worker::SQS/HTTP::1.0
Select (1 to 2): 1
Select a solution stack.
Available solution stacks are:
1) 32bit Amazon Linux 2014.02 v1.0.1 running PHP 5.4
2) 64bit Amazon Linux 2014.02 v1.0.1 running PHP 5.4
3) 32bit Amazon Linux 2014.02 v1.0.1 running PHP 5.5
4) 64bit Amazon Linux 2014.02 v1.0.1 running PHP 5.5
5) 32bit Amazon Linux 2013.09 v1.0.1 running PHP 5.4
6) 64bit Amazon Linux 2013.09 v1.0.1 running PHP 5.4
7) 32bit Amazon Linux 2013.09 v1.0.1 running PHP 5.5
8) 64bit Amazon Linux 2013.09 v1.0.1 running PHP 5.5
9) 32bit Amazon Linux running PHP 5.3
10) 64bit Amazon Linux running PHP 5.3
11) 32bit Amazon Linux 2014.02 v1.0.1 running Node.js
12) 64bit Amazon Linux 2014.02 v1.0.1 running Node.js
13) 32bit Amazon Linux 2013.09 v1.0.1 running Node.js
14) 64bit Amazon Linux 2013.09 v1.0.1 running Node.js
15) 64bit Windows Server 2008 R2 running IIS 7.5
16) 64bit Windows Server 2012 running IIS 8
17) 32bit Amazon Linux 2014.02 v1.0.1 running Tomcat 7 Java 7
18) 64bit Amazon Linux 2014.02 v1.0.1 running Tomcat 7 Java 7
19) 32bit Amazon Linux 2014.02 v1.0.1 running Tomcat 7 Java 6
20) 64bit Amazon Linux 2014.02 v1.0.1 running Tomcat 7 Java 6
21) 32bit Amazon Linux 2013.09 v1.0.1 running Tomcat 7 Java 7
22) 64bit Amazon Linux 2013.09 v1.0.1 running Tomcat 7 Java 7
23) 32bit Amazon Linux 2013.09 v1.0.1 running Tomcat 7 Java 6
24) 64bit Amazon Linux 2013.09 v1.0.1 running Tomcat 7 Java 6
25) 32bit Amazon Linux running Tomcat 7
26) 64bit Amazon Linux running Tomcat 7
27) 32bit Amazon Linux running Tomcat 6
28) 64bit Amazon Linux running Tomcat 6
29) 32bit Amazon Linux running Python
30) 64bit Amazon Linux running Python
31) 64bit Amazon Linux 2014.03 v1.0.1 running Ruby 2.0 (Puma)
32) 64bit Amazon Linux 2014.03 v1.0.1 running Ruby 2.0 (Passenger Standalone)
33) 32bit Amazon Linux 2014.02 v1.0.1 running Ruby 1.8.7
34) 64bit Amazon Linux 2014.02 v1.0.1 running Ruby 1.8.7
35) 32bit Amazon Linux 2014.02 v1.0.1 running Ruby 1.9.3
36) 64bit Amazon Linux 2014.02 v1.0.1 running Ruby 1.9.3
37) 32bit Amazon Linux 2013.09 v1.0.1 running Ruby 1.8.7
38) 64bit Amazon Linux 2013.09 v1.0.1 running Ruby 1.8.7
39) 32bit Amazon Linux 2013.09 v1.0.1 running Ruby 1.9.3
40) 64bit Amazon Linux 2013.09 v1.0.1 running Ruby 1.9.3
41) 64bit Amazon Linux 2013.09 v1.0.1 running Python 2.7
42) 64bit Amazon Linux 2013.09 v1.0.1 running Python
43) 32bit Amazon Linux 2013.09 v1.0.1 running Python 2.7
44) 32bit Amazon Linux 2013.09 v1.0.1 running Python
Select (1 to 44): [使用するソリューション]
Select an environment type.
Available environment types are:
1) LoadBalanced
2) SingleInstance
Select (1 to 2): [ロードバランサ使うかどうか]
reate an RDS DB Instance? [y/n]: [RDS使うかどうか]
Attach an instance profile (current value is "[Create a default instance profile]"):
You IAM user does not have sufficient permission. User: arn:aws:iam::324691443829:user/developer is not authorized to perform: iam:ListInstanceProfiles on resource: arn:aws:iam::324691443829:instance-profile/
Do you want to proceed without attaching an instance profile? [y/n]:
1) [Create a default instance profile]
2) aws-elasticbeanstalk-ec2-role
3) [Other instance profile]
Select (1 to 3): 1
Updated AWS Credential file at "/Users/[ユーザ]/.elasticbeanstalk/aws_credential_file".

這樣初步設定就完成了。已經在.git/config中添加了別名。
嘗試啟動一下，看看會發生什麼。


$ eb start
Start application [アプリケーション名]
Environment "[環境名]" already exists. Skipped creating.

跳过，并且在workspace/.ebextensions/目录下创建了optionsettings.[环境名]文件，我们可以看到预先在界面上设置的信息被继承过来了。

创建详细配置文件 un fichier de configuration

我已经做到这个地步了。实际上花了两天时间！要按照以下的结构来进行。按顺序执行。

    • workspace/.ebextensions/各設定ファイル.config

 

    • workspace/.elasticbeanstalk/アプリケーション・環境設定ファイル

 

    • workspace/opt/elasticbeanstalk/hooks/appdeploy/pre/*

 

    • workspace/opt/elasticbeanstalk/hooks/appdeploy/enact/*

 

    • workspace/opt/elasticbeanstalk/hooks/appdeploy/post/*

 

    • workspace/optionsettings.[環境名]

 

    workspace/その他配置するファイル達

为了部署，需要将git分支和eb分支进行映射。
请记下下述关联命令。

    • ブランチ一覧： git branch

 

    • ブランチ作成： git branch [gitブランチ名]

 

    • ブランチ切り替え：git checkout [gitブランチ名]

 

    • 現在ブランチとEB環境をマップ： eb branch

 

    • 現在ブランチがマップしているEB環境にデプロイ： git aws.push

 

    • 別EB環境を指定してデプロイ： git aws.push –environment [eb環境名]

 

    • コミット指定デプロイ： git aws.push –commit [コミット番号]

 

    • 環境の更新： eb update

 

    環境の停止： eb stop

在部署时，在服务器上始终要监视/var/log*文件夹，或者在结束时确认日志是一个好主意。尤其是/var/log/eb-tools.log中记录了部署操作的日志。在EB的Web控制台的每个环境的事件中也会输出语法错误等信息。如果无法正常工作，请检查一下。顺便说一句，我曾经把应该放在.ebextensions文件夹中的文件放在了.elasticbeanstalk文件夹中，还在YAML中打了制表符或者空格的错误，浪费了半天时间。该脚本启动时的日志会被记录在/var/log/cfn-init.log中。如果在配置文件内创建了文件，它们不会被自动删除，所以在重命名时要确保正确删除，避免遇到之前定义的操作还存在的情况。部署需要时间，所以这些时间影响了进展。

由于觉得强行在配置文件中尝试一切可能会导致某个地方出现不足的情况，所以我倾向于利用位于workspace直接下的文件，将它们复制并放置在/var/app/current/中，以使整个过程变得更简洁。

因为设置文件变得很长，所以我把源代码放在了GitHub上。
以下是我做过的简要事项。

用户相关

删除ec2-user账户、创建登录用户并设置RSA身份验证等安全措施。

快速先转换为Nginx

停止默认的Apache，并部署Nginx、php-fpm、memcache。

更改EB上的php.ini文件

由于选项太少，所以在部署时修改php.ini的想法是很常见的。当我查看正在运行的服务器时，我发现在我的城堡里：
php.ini => php-5.5.ini 符号链接
php.d => php-5.5.d 符号链接
那么只需做一件事，将应用程序用的ini放到php.d下就可以了。

谜语。
如果以这种方式进行定制，似乎可以进行各种调整！

困扰的事情或困难

使用EB启动环境时，资源会自动大量生成，如EC2、ELB、SecurityGroup等。当需要对它们进行详细设置时，必须分别进行相应的配置调整。
然后，如果想要进行一些重置并重新启动环境，则会遇到令人遗憾的情况。
特别是在终止环境时，必须修改ELB并重新编写DNS记录，这个步骤特别令人遗憾。

如果有任何需要，以上内容会随时进行补充。

参考资料：
使用PHP在AWS Elastic Beanstalk上部署应用程序

参考：
请查看以下链接：
– http://lab.sonicmoov.com/development/elastic-beanstalk/
– http://dev.classmethod.jp/cloud/aws/aws-elastic-beanstalk-rails/
– http://dx.24-7.co.jp/beanstalk/
– http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/troubleshooting.html

bannerAds