Differences between revisions 32 and 51 (spanning 19 versions)
Revision 32 as of 2013-01-09 19:08:32
Size: 8555
Editor: BrianGupta
Comment:
Revision 51 as of 2020-06-26 14:45:53
Size: 10804
Comment: link to AWS docs for AZ and Region details
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
A: EC2 is an Infrastructure as a Service Cloud Computing Platform provided by Amazon Web Services, that allows users to instantiate various types of virtual machines. A: EC2 is an Infrastructure as a Service Cloud Computing Platform, provided by Amazon Web Services, that allows users to instantiate various types of virtual machines. Refer to [[https://aws.amazon.com/ec2/|Amazon's product overview page]] for more details, FAQs, and documentation.
Line 16: Line 16:
== Q: What is an AKI? ==
A: An AKI (Amazon Kernel Image) is a preconfigured bootable kernel miniimage, that are prebuild and provided by Amazon to boot instances. Typically one will use an AKI that contains pv-grub so that one can instantiate an instance from an AMI that contains it's own Xen DomU kernel that is managed by the user.
Line 23: Line 20:
A: An instance-store instance boots off of an AMI that instantiates a non-persistent root volume that loses all data on poweroff, or hardware failure. EBS instances boot off an AMI that consists of an EBS volume that persists after powering off (stopping) an instance or in the event of a hardware failure a given instance is running on. EBS root volumes can be snap-shotted and cloned, like other EBS volumes. A: An instance-store instance boots off of an AMI that instantiates a non-persistent root volume that loses all data on poweroff, or hardware failure. EBS instances boot off an AMI that consists of an EBS volume that persists after powering off (stopping) an instance or in the event of a hardware failure a given instance is running on. EBS root volumes can be snap-shotted and cloned, like other EBS volumes. ''Debian AMIs only support EBS root volumes.''
Line 29: Line 26:
A: In "classic EC2" each instance is given a randomly assigned private IP address that maps via NAT to an also randomly assigned public IP address. VPC instances allow more control of the private (and public) IP address mappings and assignment, and as such let one assign custom private IP ranges and addresses, in addition to having the option to not assign public IP address mappings. A: Modern EC2 instances typically exist in a "VPC", or [[https://aws.amazon.com/documentation/vpc/|Virtual Private Cloud]] network. A VPC is a network overlay environment allowing the user to specify various aspects of the network topology including CIDR ranges, subnets, routing tables, and ACLs. Instances are assigned one or more network interfaces in a VPC, each of which can have one or more IP addresses. Publicly routable IPv6 addresses are available. IPv4 addressing is handled using private RFC 1918 addresses and stateless 1:1 NAT for public internet access.

A legacy "classic" networking mode exists in which each instance is given a randomly assigned private IP address that maps via NAT to an also randomly assigned public IP address. Amazon is not provisioning this feature for new accounts. VPC instances allow more control of the private (and public) IP address mappings and assignment, and as such let one assign custom private IP ranges and addresses, in addition to having the option to not assign public IP address mappings.
Line 32: Line 31:
A: An Elastic IP address is a Public IP addressed that is assigned to an individual AWS account. These IPs are assigned by region. This address can be assigned to any EC2 instance within a region and will replace the regularly assigned random public IP address. A: An Elastic IP address is a Public IP addressed that is assigned to an individual AWS account. These IPs are assigned by region. This address can be assigned to any EC2 instance within a region and will replace the regularly assigned random public IP address. EIPs can be either IPv4 or IPv6 addresses.
Line 35: Line 34:
A: An EC2 Region refers to a geographic region that is a completely autonomous set of compute resources, with their own management infrastructure. Regions do not share any resources, so they are considered completely separate for disaster recovery purposes. A: An EC2 Region refers to a geographic region that is a completely autonomous set of compute resources, with their own management infrastructure. Regions do not share any resources, so they are considered completely separate for disaster recovery purposes. Refer to [[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html|Amazon's documentation on Regions, Availability Zones, and Local Zones]] for more details.
Line 38: Line 37:
A: us-east-1 (Virginia), us-west-1 (N. California), us-west-2 (Oregon), eu-west-1 (Ireland), ap-southeast-1 (Singapore), ap-northeast-1 (Tokyo), ap-southeast-2 (Sydney), sa-east-1 (Sao Paulo) A: The [[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions|official list of regions]] grows with some regularity. In general, the latest Debian AMIs are available in all public regions. There is also the non-public [[https://aws.amazon.com/govcloud-us/|GovCloud]] region, available only to US Government agencies. At present, Debian AMIs are not published in !GovCloud, but users have requested them.
Line 41: Line 40:
A: An availability zone is a separate "failure zone" within a given region that can have resources instantiated in. Each region has it's own power grid, and physical set of hardware and resources. Availability zones within a given region have a shared management interface/infrastructure. A: An availability zone is a separate "failure zone" within a given region that can have resources instantiated in. Each availability zone has it's own power grid, and physical set of hardware and resources. Availability zones within a given region have a shared management interface/infrastructure.  Refer to [[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html|Amazon's documentation on Regions, Availability Zones, and Local Zones]] for more details.
Line 53: Line 52:
A: Cloud-init is a framework written in Python for handling EC2 userdata to configure a newly instantiated EC2 instance. See upstream project for more details: https://help.ubuntu.com/community/CloudInit A: Cloud-init is a framework written in Python configuring various aspects of a newly instantiated EC2 instance. Refer to [[https://cloudinit.readthedocs.io/en/latest/|its documentation]] for more details. Cloud-init is installed by default on the Debian AMIs, as well as AMIs published by several other Linux distributions including Ubuntu and Amazon Linux.
Line 68: Line 67:
A: The official Amazon CLI tools can be found here: http://aws.amazon.com/developertools/351 Please note these tools are not DFSG-compliant, but are officially supported by Amazon. There is an alternate set of DFSG-compliant tools, that are designed to be fully compatible called "eucatools", which can be installed via "apt-get install euca2ools". More info here [[euca2ools]] A: The [[http://aws.amazon.com/cli/|AWS Command Line Interface]], available under the DFSG-compliant Apache 2 license, can be installed via {{{apt install awscli}}} on Debian systems.
Line 71: Line 70:
A: The following page has a list of Official and unofficial Debian AMIs: [[Cloud/AmazonEC2Image]]. See also DebianBug:694035 for work in progress on a machine-readable list. A: The [[Cloud/AmazonEC2Image]] page has a list of official Debian AMIs for Amazon EC2. You can also use the [[Amazon/EC2/HowTo/awscli|aws cli]] to obtain listings in human or machine readable format.
Line 74: Line 73:
A: Anders Ingemann has created a build script for bootstrapping instances, and was used to create the official AMIs. The script can be automated as it needs no user interaction. Custom scripts can be attached to the process as well. You can download or clone the script from [[https://github.com/andsens/ec2debian-build-ami|github]]. Any bugs or suggestions should be reported via the github issue tracker. The script is packaged and will be available for install starting with Debian Wheezy. A: Stretch (and later) AMIs are created using the [[http://fai-project.org/|FAI]] tool using the [[https://salsa.debian.org/cloud-team/debian-cloud-images|debian-cloud-images]] configuration. An introduction into creating customized AMIs based on the FAI configuration can be found [[https://noah.meyerhans.us/blog/2017/02/10/using-fai-to-customize-and-build-your-own-cloud-images/|on Noah's blog]].

[[https://packages.debian.org/stretch/packer|Packer]] is another popular tool for creating AMIs. It has the ability to integrate with existing configuration management systems such as chef and puppet, and be used to create images based on customizations performed on a running instance.

Anders Ingemann has created a build script for bootstrapping instances, and was used to create the official AMIs for jessie and earlier. The script can be automated as it needs no user interaction. Custom scripts can be attached to the process as well. You can download or clone the script from [[https://github.com/andsens/ec2debian-build-ami|github]]. Any bugs or suggestions should be reported via the github issue tracker. The script is packaged and will be available for install starting with Debian Wheezy.

Also refer to [[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html|Amazon's documentation on this topic]].
Line 84: Line 89:
What is to procedure to accept AWS Marketplace terms ? Can it be done from the command line ? What is the procedure to accept AWS Marketplace terms ? Can it be done from the command line ?
Line 88: Line 93:
== Q: Where do I report issues with the images ? ==

Please report bugs to the `cloud.debian.org` pseudo-package, when they are related to the choices made when building the image (which packages to include, which customisation was made, etc.). Advanced users can add the [[https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=cloud.debian.org%40packages.debian.org|usertags]] to triage the report more precisely.
Line 89: Line 98:

== Q: Why does Debian choose to publish its official EC2 AMIs in the AWS Marketplace, requiring users to accept an agreement via the web site, when this isn't customary for distros that provide AMIs?

A:

Translation(s): none


Answered

Q: What is EC2?

A: EC2 is an Infrastructure as a Service Cloud Computing Platform, provided by Amazon Web Services, that allows users to instantiate various types of virtual machines. Refer to Amazon's product overview page for more details, FAQs, and documentation.

Q: What is an instance?

A: An EC2 instance is a Virtual Machine running on Amazon's EC2 Cloud.

Q: What is an AMI?

A: An AMI (Amazon Machine Image) is a preconfigured bootable machine image, that allows one to instantiate an EC2 instance. (EC2 Virtual Machine)

Q: What is EBS?

A: EBS stands for Elastic Block Storage, and is a service that provides dynamically allocatable, persistent, block storage volumes that can be attached to EC2 instances. Most system operations that can be performed with an HDD can be performed with an EBS volume. e.g. - formatted with a filesystem and mounted. EBS also provides additional SAN-like features such as taking snapshots of volumes, and detaching and reattaching volumes dynamically. One notable feature that SAN LUNs support that EBS volumes do not is muti-initiator. (IE: Only a single EC2instance can be associated with a given EBS volume at a given time, so shared storage clustering is currently not supported.)

Q: What is the difference between an instance-store AMI/instance and an EBS AMI/instance?

A: An instance-store instance boots off of an AMI that instantiates a non-persistent root volume that loses all data on poweroff, or hardware failure. EBS instances boot off an AMI that consists of an EBS volume that persists after powering off (stopping) an instance or in the event of a hardware failure a given instance is running on. EBS root volumes can be snap-shotted and cloned, like other EBS volumes. Debian AMIs only support EBS root volumes.

Q: What is the difference between terminating an instance and stopping an instance?

A: Please note this difference is only applicable to EBS-root instances. When one stops an instance it basically virtually powers off the instance but it remains in the inventory to be powered on (started) again. Terminating an instance removes its records from the system inventory and usually also deletes its root volume.

Q: How does IP addressing work in EC2?

A: Modern EC2 instances typically exist in a "VPC", or Virtual Private Cloud network. A VPC is a network overlay environment allowing the user to specify various aspects of the network topology including CIDR ranges, subnets, routing tables, and ACLs. Instances are assigned one or more network interfaces in a VPC, each of which can have one or more IP addresses. Publicly routable IPv6 addresses are available. IPv4 addressing is handled using private RFC 1918 addresses and stateless 1:1 NAT for public internet access.

A legacy "classic" networking mode exists in which each instance is given a randomly assigned private IP address that maps via NAT to an also randomly assigned public IP address. Amazon is not provisioning this feature for new accounts. VPC instances allow more control of the private (and public) IP address mappings and assignment, and as such let one assign custom private IP ranges and addresses, in addition to having the option to not assign public IP address mappings.

Q: What is an Elastic IP Address (EIP)?

A: An Elastic IP address is a Public IP addressed that is assigned to an individual AWS account. These IPs are assigned by region. This address can be assigned to any EC2 instance within a region and will replace the regularly assigned random public IP address. EIPs can be either IPv4 or IPv6 addresses.

Q: What is an EC2 Region?

A: An EC2 Region refers to a geographic region that is a completely autonomous set of compute resources, with their own management infrastructure. Regions do not share any resources, so they are considered completely separate for disaster recovery purposes. Refer to Amazon's documentation on Regions, Availability Zones, and Local Zones for more details.

Q: What EC2 Regions are there?

A: The official list of regions grows with some regularity. In general, the latest Debian AMIs are available in all public regions. There is also the non-public GovCloud region, available only to US Government agencies. At present, Debian AMIs are not published in GovCloud, but users have requested them.

Q: What is an EC2 Availability Zone?

A: An availability zone is a separate "failure zone" within a given region that can have resources instantiated in. Each availability zone has it's own power grid, and physical set of hardware and resources. Availability zones within a given region have a shared management interface/infrastructure. Refer to Amazon's documentation on Regions, Availability Zones, and Local Zones for more details.

Q: What is an EC2 Security Group?

A: A Security Group (SG) is a management construct within EC2 that acts similarily to a network based firewall. An instance must be assigned one or more security groups at first instantiation. Security group membership may not change after initial instantiation. Security groups allow one to set incoming network rules allowing certain TCP/UDP/ICMP protocols ingress via rules based on incoming security group ID, network address or IP address. Security groups do not restrict outbound traffic, nor do they restrict traffic between instances within the same security group. (Assuming they are communicating via their private IP addresses.)

Q: What is instance metadata?

A: Instance metadata is descriptive information about a particular instance, that is available via an http call to a particular instance and that instance alone. e.g. - Public IP address, availability zone, etc. userdata is one of these pieces of data available.

Q: What is userdata?

A: When one instantiates an EC2 instances one may optionally pass 16 KB of data to the API that can be used by the instance. (Typically use cases are running scripts, and/or configuring the instance to meet a particular use case.)

Q: What is cloud-init?

A: Cloud-init is a framework written in Python configuring various aspects of a newly instantiated EC2 instance. Refer to its documentation for more details. Cloud-init is installed by default on the Debian AMIs, as well as AMIs published by several other Linux distributions including Ubuntu and Amazon Linux.

Q: How do I log into a Debian EC2 instance for the first time?

A: When you instantiate an instance from an official Debian AMI, one needs to assign a previously uploaded/created ssh public key, which will be added to the "admin" user's authorized_keys. One can then ssh in as "admin" and use sudo to add additional users.

Q: What are the different methods supported to manage EC2?

A: Either via the AWS Web Console, via the API, or via CLI tools.

Q: How do I get to the AWS Web Console?

A: https://console.aws.amazon.com/

Q: Where is the EC2 API documented?

A: http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/Welcome.html

Q: Where can I find the CLI tools to manage EC2?

A: The AWS Command Line Interface, available under the DFSG-compliant Apache 2 license, can be installed via apt install awscli on Debian systems.

Q: Where can I find the list of Official Debian AMIs?

A: The Cloud/AmazonEC2Image page has a list of official Debian AMIs for Amazon EC2. You can also use the aws cli to obtain listings in human or machine readable format.

Q: How can I build my own AMI?

A: Stretch (and later) AMIs are created using the FAI tool using the debian-cloud-images configuration. An introduction into creating customized AMIs based on the FAI configuration can be found on Noah's blog.

Packer is another popular tool for creating AMIs. It has the ability to integrate with existing configuration management systems such as chef and puppet, and be used to create images based on customizations performed on a running instance.

Anders Ingemann has created a build script for bootstrapping instances, and was used to create the official AMIs for jessie and earlier. The script can be automated as it needs no user interaction. Custom scripts can be attached to the process as well. You can download or clone the script from github. Any bugs or suggestions should be reported via the github issue tracker. The script is packaged and will be available for install starting with Debian Wheezy.

Also refer to Amazon's documentation on this topic.

Q: How can I accept AWS Marketplace terms ?

Attempts to run an official Debian AMI from a naive account return error messages such as the following.

OptInRequired: In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit http://aws.amazon.com/marketplace/pp?sku=8fvdn95s5ev33cprr62nq3q7t

What is the procedure to accept AWS Marketplace terms ? Can it be done from the command line ?

A: The terms and conditions for Marketplace published AMIs can only be accepted via the web site, and not via the command line or API directly. The EULA is required to be shown to the customer (in the case of the Debian AMIs in Marketplace, it is the Debian Social Contract which is displayed to the customer).

Q: Where do I report issues with the images ?

Please report bugs to the cloud.debian.org pseudo-package, when they are related to the choices made when building the image (which packages to include, which customisation was made, etc.). Advanced users can add the usertags to triage the report more precisely.

Unanswered