AWS EC2 基于 Lambda CloudWatch配置自动定时开机

操作参考文档:
第一篇
第二篇

主要步骤:
1. 为 Lambda 函数创建自定义 Identity and Access Management (IAM), 即: 策略和执行角色。
2. 创建 停止/启动 EC2 实例的 Lambda 函数 (基于python)。
3. 创建 按计划触发您的函数的 CloudWatch Events 规则。

注意事项:
1. Lambda函数写好之后,只是 save 还不会每一次,一定要点 Deploy 新的代码才会实际生效
2. cron 任务的设置要注意,这里多了一个年份的值,
3. 特别要注意: Cron 表达式中为日期和星期几字段同时指定值。如果您在其中一个字段中指定了值(或一个 *),则必须在另一个字段中使用 ?(问号)。
4. cron 里的时间使用的是 UTC 时间,不是北京时间。换算时间时要用北京时间减去8小时才是UTC时间.

wordpress 服务重启 网页打开次数较多后 报内存不足

实际解决方案:

先找到占用内存严重的进程:
打印占用内存前10的进程:
ps aux | sort -k4,4nr | head -n 10

明确了是/usr/sbin/httpd -k start 这些进程在不断消耗内存,
与之前一直在查的PHP不是一回事,根本不是php在消耗内存。
而是httpd进程把内存消耗光了,造成php请求内存失败

httpd -V 看编译情况及加载的配置文件

修改了:
sudo vi httpd.conf , 把:#Include conf/extra/httpd-mpm.conf 前的”#”去掉了
/etc/httpd/extra/httpd-mpm.conf event里的参数,都改小了

这样修改httpd-mpm.conf就生效了。

 

 

下面这段是之前写的,文章刚要发布就因为内存不足而卡死:

背景: 升级apache到2.4, php重装后,访问wordpress网站经常会出现:Fatal error: Out of memory, 看后台error_log:  mmap() failed

尝试过多种方法都没有效果。

访问插件:http://www.xxxxxx.com/wp-admin/admin.php?page=aiowpsec&tab=tab2

在wordpress控制台内,看到PHP的内存是256M,但在服务器的配置文件中,看到的都是128M。说明配置哪里没有统一。因不知道那个256M的值是从哪里读取的,先把已知配置文件中,128M修改成256M:

vi ./wp-includes/default-constants.php,
发现这个文件里有两个变量限制内存大小 :WP_MEMORY_LIMIT WP_MAX_MEMORY_LIMIT

修改:wp-config.php,定义这2个变量的值如下:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);

修改之后,重启httpd服务,没有再发生内存不足的问题。

 

LAMP升级apache2.2 到 apache2.4踩过的坑

背景:要在apache中添加部署Django项目,要安装mod_wsgi这个模块,结果因为apache的apxs的版本有冲突无法安装。眼看自己的apache版本还是2.2,于是寻思着对Apache进行升级,于是踩坑之旅就此开始,熬过了2个凌晨2点钟。

Apache升级:原来考虑的最简单的思路莫过于直接yum update apache,结果有冲突,无法卸载也无法升级。最后直接下载了源码编译安装。

Apache安装完之后,原来Wordpress博客的网页无法正常加载,访问博客网址,刚开始是一访问就会直接触发一个下载动作。后面调试后,变成直接会把html文件夹根目录下的index.php文件的内容打印出来。试过执行了info.php,结果也是直接在网页上直接返回这个文件的内容。

看到测试的info.php都不能正常执行,猜测试是PHP有问题,网上一查,说是apache没有加载PHP模块导致。之前我的PHP版本刚升级过,是使用YUM操作的,服务器里没有编译生成过libphp7.so。各种尝试无果之后,果断决定升级PHP。

也是先考虑用yum update php来操作,结果也是各种冲突,升级也不行,卸载也不行。于是决定下载PHP源码自己编译安装。刚开始执行源码 ./configure的时候,参数使用官网默认提供的,装完之后,才想到没把mysql统计进php,于是又网上查找LAMP搭建时,PHP源码编译的参数,安装过程中各种包找不到,./configure失败重新补充安装缺少的组件。

PHP安装完之后,把:libphp7.so加载到apache的模块中。发现访问博客网站还是出现 Index of 的页面,直接把html根目录的文件全部暴露。这个时候,查找apache logs下的error_log,发现提示.htaccess的问题,再网上搜索,说的是apache2.4 跟apache2.2 的httpd.conf有些配置语法是不一样的。连猜带蒙改了httpd.conf, .htaccess。改完之后,error_log里这个报错是没有了,但是博客还是返回Index of,但这时info.php已经能正常返回了,说明我的PHP已经能正常工作。这中间穿插了:”AddType application/x-httpd-php” 的配置问题,没有这一句,apache无法正常处理php后缀的网页文件。

现在基本可以排除PHP的问题。

接下来继续上网查,发现会返回“Index of”是因为apache找不到网站访问初始打开的页面,默认是index.html,于是默认就会把html根目录下的文件列表返回至网页上。

需要修改httpd.conf:

把这一句:“Options Indexes FollowSymLinks”改成“Options FollowSymLinks”

这样就不会返回文件名列表,而是会直接提示 Forbidden。
再把“DirectoryIndex index.html”改成“DirectoryIndex index.html index.php”就可以让apache自动搜索index.php来加载网站了。

现已能正常打开博客网站。

但是,这个时候又发现了新的问题,网站只是主页能打开,博客文章目录里的链接点开会报链接不存在。好在这个问题以前就处理过,并且有写文章记录下解决方案,找到旧的博文,发现是mod_rewrite.so没有加载导致。编辑下httpd.conf,把mod_rewrite前的注释去掉就行了。

至此,整个博客网站的访问就全恢复正常了。

这下,原来要部署的Django网站的活可以重新排上日程了。。。

这篇博文刚写完要保存,发现还有问题,后台报:mmap() failed: [12] Cannot allocate memory, 先重启httpd服务修复。

[个人笔记] EC2 PHP 5.3 升级到 7.0

WordPress安全提示,反馈系统的PHP版本太低,建议升级。

升级步骤:

1. 兼容性检查:

安装了php兼容性检查插件,发现升级到PHP 7.0后,可完全兼容当前环境下的所有插件。

2.EC2服务器创建快照,升级后如果有问题可以回退。

3.备份当前服务器下的HTTPD,PHP安装文件夹及配置文件。

4.停httpd服务:

sudo service httpd stop

5.删除旧版HTTPD, PHP:

sudo yum remove httpd* php*

6.安装新版httpd, php:

sudo yum install httpd24

sudo yum install php70

7.检查软件版本:

rpm -qa |grep -i http

rpm -qa |grep -i php

php -v

8.启动新的httpd:

sudo service httpd start

sudo chkconfig httpd on (设置开机服务自启动)

9.检查端口监听情况:

netstat -an |grep 80

10.浏览器访问wordpress网站:

页面报错:

Your PHP installation appears to be missing the MySQL extension which is require

解决方法:

sudo yum install php70-mysql*

11.再次浏览器访问wordpress网站,成功,可正常访问。

EC2服务器Apache下 /var/www/目录权限的配置

EC2上, Apache 文档根目录默认的路径为: /var/www/html, 因为这个目录有可能被不同用户访问, 如果不修改默认权限配置的话,后续无法使用不同用户对这个路径下的内容进行更新.

思路: 把要操作这个路径的所有用户都加到同一个组: apache.

配置步骤:

当前用户: ec2-user

原来安装apache的时候, 已自动生成apache 组.不再另外添加新的组.

1.将ec2-user加入apache组, 参数a表示append:

sudo usermod -a -G apache ec2-user

执行后可通过 groups这个命令来查看当前用户都在哪些组中.

2.将 /var/www 及其内容的组所有权更改到 apache 组:

sudo chown -R ec2-user:apache /var/www

若单独更改组, 可执行下面这条命令:
sudo chgrp -R apache /var/www

3.递归添加组写入权限:

sudo chmod 2775 /var/www
find /var/www -type d -exec sudo chmod 2775 {} \;
find /var/www -type f -exec sudo chmod 0664 {} \;

4.重启Apache Web服务器, 让新的组和权限生效:

sudo service httpd restart

现在,ec2-user 用户 (以及 apache 组的任何未来成员) 可以在 Apache 文档根目录中添加、删除和编辑文件。

5.后续有新的用户ftpuser要更新/var/www/下的内容, 可将它加入组apache中:

sudo usermod -a -G apache ftpuser

Amazon EC2 RDS迁移到新的区域

之前创建EC2实例的时候,没有注意到区域的问题,后面才发现所创建的实例被设置在了美国东部的Ohio,从大陆访问的话,加载速度太慢,于是研究了一下如何切换区域。

这里先要明确AWS里两个概念: available region和 available area.

1. Region是指一个大的区域,比方说:california, tokyo, Ireland这些地方就是AWS有提供服务的一个区域。

2.Area是同一个区域划分出来的多个区,一般AWS在每个Region都会搭建若干个Area。

本文所指的迁移,是从一个区域到另外一个区域的迁移。

下面开始步入正题:

1.首先,因为这次是要优先保证从中国大陆访问EC2的速度,所以可以先通过工具测试下杭州到每个有提供AWS服务的城市的网络延时,具体可访问这个网址来得到测试数据:

http://www.cloudping.info/

可以多测试几次,综合判断出最适合自己访问速度最满意的地方。

下面我们将以从Ohio迁移到California为例进行说明。

2.迁移EC2,主要操作步骤如下:

控制台右上角的Region先选择Ohio

2.1 对Ohio当前EC2创建AMI镜像:

Instances->选择虚拟机 -> Actions: Image -> Create Image
Update the permission if you need:
Images->AMIs-> select AMI -> Actions-> Modify Image Permissions

2.2 把新创建好的镜像从 ohio 拷贝到 california:

Images->AMIs-> select AMI -> Actions->Copy AMI->Choose Destination region

2.3 把控制台右上角的区域切换至california:

launch new EC2 instance -> select custom AMI -> Your AMI from Ohio

后面的步骤按个人需要进行配置就行。

需要特别说明的是, 迁移后,California这边的安全组需要另外再配置一遍。同时,要重新配置SSH访问的证书。

如下旧的EC2实例不需要再使用,记得把它关掉,以免被计费。

 

3. 迁移RDS,主要操作步骤如下:

控制台右上角的Region先选择Ohio

3.1 先对Ohio这边的RDS创建快照:

Instance -> select DB instance -> Instance actions -> Take snapshot

3.2 把创建好的快照拷贝到California:

Snapshots -> select Snapshot -> Snapshot Actions -> Copy Snapshot -> Copy to California

3.3 把控制台右上角的区域切换至california:

Snapshots -> select Snapshot -> Snapshot Actions -> Restore Snapshot

3.4 配置下安全组。

3.5 更新下EC2实例中数据库访问的地址信息。

简要步骤就是上面这些。