nvm是一个nodejs版本管理工具，它能够方便地帮助你管理多个共存的nodejs版本，并在其中进行自由切换。

　　这回在AWS的CodeDeploy脚本中调用nvm自动安装和使用指定版本的nodejs，遇到了问题。如下的脚本，

　　执行后发现，最终部署结果里并没有使用5.3.0的nodejs，而使用的仍然是系统原来安装的老版本。ssh登录机器，查看nvm ls和nvm current，却已然是5.3.0版本的nodejs了：

　　原来nvm的所有命令，如nvm install，nvm ls都是写在~/.nvm/nvm.sh脚本里的，系统之所以能识别这些命令，是因为在当前shell里运行过source ~/.nvm/nvm.sh。而正因为已经在~/.bashrc文件中添加了该语句，所以每次ssh登录时，shell相当于已经source过了该脚本。

　　而以”su -c”方式执行命令时，命令是在一个non-login，non-interactive的shell执行的，所以不会读取~/.bashrc文件，因此nvm的命令就无效了。解决办法是在CodeDeploy脚本中调用nvm命令的语句前，先使~/.nvm/nvm.sh文件source一下。比如：

　　参考：

• What is the difference between interactive shells, login shells, non-login shell and their use cases?
• What’s the difference between .bashrc, .bash_profile, and .environment?

　　AWS CodeDeploy是亚马逊云计算提供的服务之一，用来将代码更容易地部署到EC2实例或私有云实例中。

　　它能够根据用户配置，从S3或Github上获取最新代码，并按照用户提供的appspec.yml配置文件，在不同的hook事件阶段执行不同的脚本文件，从而使代码部署过程自动化。

　　比如你可将多个EC2实例分为Dev，QA，PRD三组，通过结合CodeDeploy和其他CI工具(如Jenkins），自动化完成持续交付（部署到Dev/QA实例上），持续部署（部署到PRD实例上）的任务。

　　在使用CodeDeploy的过程中，有以下几点事项需要注意：

• 所有EC2实例上必须安装CodeDeploy Agent服务，EC2实例之所以会响应CodeDeploy服务，都是由CodeDeploy Agent来完成工作的。
• 默认CodeDeploy Agent是通过root用户安装的，所以appspec.yml中执行脚本时，默认是以root用户身份执行。而我们的代码中用到了PM2，执行PM2命令（如pm2 start）时，需要在appspec.yml中指定以ec2-user用户执行脚本，否则相关命令执行时，会导致EC2实例cpu持续占用100%，最终导致超时而部署失败。
• sudo: sorry, you must have a tty to run sudo问题。在sh脚本中，如有需要sudo执行的命令，则需在所有EC2实例的/etc/sudoers文件中，注释掉“Default requiretty”一行。
• /bin/bash^M: bad interpreter: No such file or directory问题。这是因为在windows操作系统上修改了.sh文件，导致文件末行编码不同，而在linux机器上无法执行。解决办法是在linux机器上重新保存该文件，或在windows上用sublime打开该文件，View->Line Endings->选择Unix，保存即可。

　　背景：拟在Amazon EC2上部署nodejs应用集群。假设nodejs部署在A和B两台机器上，通过前端的ELB（Elastic Load Balancer）分发请求到A和B机器上，两台机器分别对请求做无状态响应，这样就要求A和B机器存取完全相同的数据。由于nodejs应用需要读写本地硬盘目录（对响应速度要求高，无法采用S3存储），而Amazon目前提供的存储方案中，只有EBS（Elastic Block Storage）存储可以挂载到具体机器上以提供本地路径，所以只能选取EBS作为应用集群的存储位置。但EBS类似SAN，只能挂载到一个EC2实例机器中，如果直接挂到A或B上的话，另一台机器就无法读取其中数据。所以采用的方案是启动第三个EC2实例机器C，将EBS挂载到C机器上后，该机作为NFS服务器共享EBS的挂载目录，A和B机器作为NFS客户端，分别加载共享出来的EBS路径到各自对应目录，从而保证nodejs集群能够实时读写相同的数据。如下图所示：

　　问题：在C机器上挂在EBS存储卷后，修改/etc/exports文件设置了NFS共享，并且有rw, no_root_squash选项。但在A机器和B机器上通过修改/etc/fstab文件并mount -a后，发现能够加载C机器上的EBS存储到指定目录，但写入文件时提示无权限。

　　解决办法：确保C机器（NFS服务器）上，EBS挂载路径的所有者，与A和B机器（NFS客户端）上准备写入数据的用户要拥有相同的UID和GID。具体来说，这三台机器都是从Amazon Linux的AMI启动的，所以默认用户都是ec2-user（非root用户）。C机器上EBS挂载点是/data，一开始该目录的所有者和组均为root（因为在根目录下建立目录需要root权限），所以导致在A和B机器上加载该共享目录后，加载目录的所有者和组也均为root用户。这样A和B机器上运行nodejs的ec2-user用户就无法写入数据了。解决的具体办法是在C机器上运行”sudo chmod –R ec2-suer:ec2-user /data”命令后，在A，B机器上重新加载NFS共享目录即可。

　　参考：How to properly set permissions for NFS folder? Permission denied on mounting end.

　　目前Amazon EC2上推出了公测版的EFS（Elastic File System）存储，类似NAS，在可以提供本地存储路径的前提下，还可以挂载到多台EC2实例上。但目前只有US West(Oregon)一个区域可用。在EFS全面推出前，采用上述方案，可保证应用集群横向扩展的情况下，依然能存取相同的数据。缺点是C机器是单故障点；但数据存储在单独的EBS上，至少保证数据的生命周期不依赖具体的EC2实例机器。