ec2

参考资料： 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时也会遇到相同的报错： 1 Client.OperationNotPermitted: 2 'vol-xxxxxxx' with Marketplace codes may not be attached as a secondary device. 这个Marketplace code，顾名思义

通过Portworx云原生存储，在Amazon EKS里运行高可用SQL Server容器 在本文我们将分析，如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS, https://amazonaws-china.com/eks/)，来在容器中部署Microsoft SQL Server。文中讨论的方式和与原理，也适用于其他需要高可用和持久性、并符合可复用的DevOps方式的有状态应用。例如运行MongoDB、Apache Cassandra、MySQL、或者大数据处理等。 首先能够被支持在容器中运行的是SQL Server 2017版本。我们可以在Linux容器中，使用Kubernetes (https://amazonaws-china.com/kubernetes/)来运行SQL Server生产负载。 Microsoft SQL Server是被广泛使用的数据库。SQL Server提供一系列很不错的功能，也有很不错的开发者社区。但是它需要比较多的运维，也比开源的或者云端的数据库成本要更高。很多为了降低成本的用户会转向开源方案来降低软件授权的成本。另一些用户会迁移工作负载到关系数据库管理系统（RDBMS）服务里，比如Amazon RDS for Microsoft SQL Server或者Amazon

同事前两天打算重启一个EC2 实例，结果手滑点到了 Termination，然后EC2 就悲剧了。幸好有Snapshot备份，服务器挂了15分钟之后 成功的恢复了。 可以看见 reboot和terminate靠的十分近，所以为了避免悲剧再次发生，我们需要打开 termination protection 如果只有几台EC2，可以手动点开，如图所示 但是如果很多的话，还是写脚本实现方便一些 下面是PowerShell实现的操作。 function Scan-EC2(){ Write-Host "Checking EC2 instance Tags status" -ForegroundColor Yellow $all=Get-EC2Instance | select -expand instances # confirm EC2 instances were tagged $result=@() foreach($item in $all){ $Name=$item.tag | Where-Object {$_.Key -eq 'Name'} | select -ExpandProperty value $clinic=$item.tag | Where-Object {$_.Key -eq 'clinic'} | select -ExpandProperty value

这个是第一个Cloudformation的新手练习，简单记录一下流程。这个练习是为了大致的熟悉一下基本流程 Cloudformation是AWS的一个很重要的服务，简单的说他的功能就是为了实现 infrastructure as code。管理员通过创建template文件，在cloudformation里面执行，就可以生成对应的stack。这里的关系有点类似于面向对象编程里面，类和实例化的对象一样。用户可以通过参数传入值，然后根据template（类）生成 stack(实例化的对象）。 管理员可以通过JSON或者YAML两种格式来模板。AWS里面，这两种格式可以互相切换。YAML的重要优势在于可以在文档里面写注释，而JSON不可以，所以未来的趋势肯定是YAML。模板里面可以定义9个部分，但是除了resource是必须的话，其他都是可选的配置。 https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html 下面来看看具体的例子 AWSTemplateFormatVersion: 2010-09-09 Description: >- This template creates an EC2 instance based on the region and selection

AWS 目前是世界上市场份额最大的云服务商，在国内的市场比例因为各种原因远远比不上阿里云，但是在国际市场上，尤其是IaaS 这一块，AWS，Microsoft和 Google 几乎是三分天下。 云是否便宜？ 这是一个相对有争议性的话题，我抛砖引玉说说自己的看法。一般说起云服务，很多用户的第一反应就是便宜。从成本考虑的话，因人而异，我不认为云服务就一定会比线下的服务器更便宜。豆子的部门需要对集团旗下140多个大大小小的子公司进行IT的运维，经常有用户会问我们，如果我的服务器迁移到AWS上，大概一个月多少钱？上云之前，一般都会进行简单的成本计算进行对比，包括硬件成本，软件成本，人工成本以及各种维护的成本，包括机房的备份，UPS，空调等等。从效率上来说，IaaS的优越性在于可以让管理员完全忽略掉底层的存储，网络，主机，以及机房的相关配套设备，仅仅关注自己需要的服务上面，从人工的工时上节约了大量的时间和金钱；个人认为，对于一些大的公司而言，基础的机房建设投资不菲，上云肯定能节省大量的金钱和精力；但是对于某些小的客户而言，高可用的存储主机网络本来就不是他们关注的重点，一个普通的服务器足够满足所有的需求了，因为他们的IT的预算本来就很低，那么上云并不会节约太多开支。 AWS云服务和相关费用考虑 对于AWS来说，上云之前需要考虑哪些服务和费用呢？如果忽略掉潜在的重要开支

一、背景介绍 假定我们有一个 PHP 的应用程序，代码发布不需要进行编译，应用程序在 AWS 的 EC2 上面或者 On-Premises，在实现 CI/CD 的方式上面有很多方法，那我们如何利用 AWS 的 Develop Tooles 去实现呢？ 在这里，我首先介绍一下我们可能会用到的 AWS 服务： IAM ：配置 CodeDeploy，CodePipeline 相关的权限； CodeCommit ：应用程序代码存储库； CodeDeploy ：EC2/On-premises 平台的应用部署程序； S3 ：CodePipeline 过程中文件的存储位置，为整个 pipeline 过程提供文件来源； CodePipeline ：管理整个 pipeline 过程。 Amazon EC2 ：应用程序存放的服务器。 二、配置 EC2 2.1、为 EC2 创建 Service role 因为在整个 CI/CD 过程中，EC2 服务器需要从 S3 获取资源，我们这里就索性给了 AmazonS3FullAccess 。 https://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam

1、MySQL安装： EC2直接使用yum安装mysql非常方便： yum install mysql mysql-server mysql-libs 此处安装了三个包 完事之后能够直接使用 service mysqld start 启动mysql服务 改动root密码： mysqladmin -u root -p password “root” 2、使用mysqld_multi安装多实例mysql： vim /etc/my.cnf 加入实例的配置信息 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid 以上是默认的配置信息，在mysqld下加入例如以下配置： #开启慢查询日志， 记录查询过长的 sql 语句。以便于优化 log_slow_queries=/var/log/mysql/mysql-slow.log #开启 bin-log 日志，不用log-bin=xxx。试验时这样子无法启动mysql服务，不知为何 log-bin #分配serverid。不要和以下的从服务器冲突就可以 server-id=1

AWS 安全组是作用在每一个实例上的网络安全控制单元，相当于传统数据中心的防火墙，它是一个有状态的防火墙，安全组规则可控制允许到达与安全组关联的实例的入站流量以及允许离开实例的出站流量。，一般我们只需要设定它允许的入站协议端口即可。 下面以一个Web服务器（面向Internet,放在公有子网）和数据库服务器（只接受Web服务器的访问，放在私有子网）的安全组设置作为示例。 1、 创建一个Web 服务安全组，命名为“SG-web” 开放80、443、22端口。并把此安全级引用至创建的EC2中 注意上图中的SSH “Source”的下拉框中选择了“My IP”自动会填充为您当前访问AWS控制台所用的公网IP。建议用这样的方式来设置SSH的“Source”这样设置就只有您当前所有的IP地址可以连接这个EC2实例，安全风险更小。 创建完成后在控制台安全组列表中可以看到。 之后再创建Web EC2实例，并在第6步“选择一个现有的安全组”，选中已创建的“SG-Web”此EC2启动后就开放了80.443、和22端口。 2、 创建一个数据库服务器安全组，命名为”SG-DB” 开放3306和22端口（用于数据库的日常管理）。并把此安全组引用到新创建的DB EC2中。 注意下图的“source”都是选择的“custom”并且用“SG-Web” 安全组作为“source”。这样做的原因是DB

AWS实例类型的选择对应用性能和成本都有关联，所以选择合适的实例类型，既能保证应用性能，又节约成本，获得最佳的性价比。 如果是本地迁移上云项目，首先要做的是收集线下数据中心X86服务器的信息，最基本的例如CPU核数，CPU峰值利用率，内存大小（GB），内存峰值利用率，操作系统类型。我们想根据这些基本信息估算一下在云上应该选择何种机型，以及一年的费用大约是多少。大多数客户在上云后都会购买一年标准RI实例以节省费用，所以我们就以一年全部预付费标准RI的价格作为选择机型的依据。选择机型的逻辑是：满足内存和CPU需求的最便宜的机型。 当然，由于我们买的是一年标准RI实例，在一年之内不可改变机型配置，所以也应该考虑预留一年的业务增长量。因此，在以上收集的基本信息的基础上，我们还要加上两条：我们期望的CPU利用率和内存利用率。举例来说，如果您目前的某个服务器的CPU和内存利用率是90%和80%， 您预计在一年内业务会有20% 的增长（我们姑且认为业务增长与资源需求成正比），当前的CPU是4核，内存是16GB。如果你希望当业务增长20%后，服务器的CPU和内存的利用率维持现状，即90%和80%， 选择的EC2机型应该在运行现有负载时的期望CPU利用率是90%/1.2=75%, 期望的内存利用率是80%/1.2=67%。 还有一点需要考虑的就是应用系统的特性，是以计算能力为主的还是以内存大小为主

我有一个Amazon EC2微实例（t1.micro）。 我想将此实例升级为大型。 这是我们的生产环境，那么最好和无风险的方法是什么？ 有没有一步一步指导这样做？ #1楼 根据我的经验，我的方式是创建当前图像的快照，然后一旦完成，您将在启动新实例时将其视为一个选项。 只需在此时将其作为大型实例启动。 如果我不想要任何停机时间（即生产服务器），这是我的方法，因为此解决方案仅在新服务器启动并运行后才使服务器脱机（我还使用它通过使用此方法将新机器添加到我的集群中）只添加新机器）。 如果停机时间可以接受，请参阅Marcel Castilho的回答。 #2楼 在大型实例上创建AMI - >引导AMI。 更多信息 http://docs.amazonwebservices.com/AmazonEC2/gsg/2006-06-26/creating-an-image.html 您也可以在aws.amazon.com上从管理控制台执行此操作 #3楼 使用AWS EC2控制台，而不是ElasticFox。 第一种方式： 创建实例的新AMI 启动它 替代方式： 制作磁盘 快照 启动 具有相同AMI类型 的大型EBS实例 （请注意，此时磁盘将包含创建此AMI时存在的数据，而不是最新更改） 完全启动后， 停止新实例 从已停止的实例中 分离根卷 从之前在新实例的同一可用区中创建的快照创建 虚拟磁盘