##(see the SpecSpec for an explanation) * '''Launchpad Entry''': UbuntuSpec:server-lucid-puppet-uec-ec2-integration * '''Created''': MathiasGug * '''Contributors''': * '''Packages affected''': == Summary == ## This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. Best practices for deploying a puppet based infrastructure in EC2/EC2 will be documented. A default puppet master configuration will be developed. An ec2-init module to configure an instance as a puppet client on first start will be integrated into the default UEC/EC2 images. == Release Note == ## This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) ## It is mandatory. UEC and EC2 Ubuntu images can easily be integrated in EC2 or a UEC cloud managed by puppet. == Rationale == ## This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. EC2 and UEC enables dymanic scaling of instances. Puppet is the configuration management system available in main - it should be easy to deploy new instances based on the Ubuntu images and have them integrated in a puppet environment. == User stories == * Henri, a system administrator, uses Amazon Auto Scaling feature for EC2 to launch new web frontends for his website. He uses puppet to manage all of his services in located in EC2. He can just start the base Ubuntu Server image and have it automatically register in his puppet infrastructure. * Laura, a system administrator, is asked to deploy a temporary web site expected to have high traffic. She wants to deploy her Ubuntu Servers based systems on EC2 with puppet. She reads up on the best practices to setup a puppet infrastructure in EC2. == Design == ## You can have subsections that better describe specific parts of the issue. Since instances can be automatically started by an external service (ie not by the puppet master) any manual step needs to be avoided. Defining puppet nodes and accepting CSR are thus impossible. In order to automate the whole infrastructure: 1. The puppet master automatically signs any csr it receives. 1. Each puppet client (instances) declares what kind of node (via a class fact) it will be. === Bootstrap process === 1. The newly instances grabs the following information from the user-data: i. ip of the puppet master i. the ca cert of the puppet master i. the class of the instance 1. Client generates a private key and csr during the first start (default behavior). 1. Client sends the csr to the puppetmaster. 1. The puppet master '''automatically''' accepts the csr. 1. The puppet manifest logic leverages the class fact to generate the correct node manifest. WI: Provide a puppet recipe to setup a puppet master providing a working configuration in UEC/EC2: TODO WI: Document the security policies needed to secure the puppet master and the EC2/UEC network infrastructure: TODO === ec2-init puppet module === A specific ec2-init puppet module supports the following user-data information: * ip/hostname of the puppet master (mandatory) * puppet master ca cert (mandatory) * puppet client private key (optional) * puppet client certificate (optional) * class of the instance (optional) The module will be responsible for install the puppet client package and boot strap the client registration. WI: Write an ec2-init module that sets up a puppet client: TODO == Implementation == ## This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: Work items are tracked in the [[UbuntuSpec:server-lucid-puppet-uec-ec2-integration|blueprint]]. == Test/Demo Plan == ## It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. ## This need not be added or completed until the specification is nearing beta. == Unresolved issues == ## This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == === UDS Session notes === A puppet master service should be provided as part of the UEC installation. UEC/EC2 images should also support a puppet environment where instances can be booted and automatically be configured via puppet. === puppet support in UEC images === start an UEC instance and automacally the instance registered into an existing puppet infrastructure bootstrap process: * client gets a certificate signed by the server default process: * client generate a private key and a csr * human accepts (signs) the client csr on the server Option: 1. provide the private key, the cert and the ca cert to the instance via user-data Mitigation: Store the private key, cert ca cert in S3 and use an expiring URL. Firewall off user-data Issue with multiple instances being started. Use case: auto-scaling: EC2 will start automatically: no way to get generate the certificate before starting. user data will have the class/type in puppet - the puppet maninfest logic can leverage that info as a fact. Use the same private/certificate for a each class and shared between instances. User-data content: * ip of puppetmaster * the class of the client (opt) * private key/cert/ca cert (opt) * puppet configuration file Autodiscovery of the puppetmaster: * client puppet A record (dns) * avahi in the private EC2 network * through user data === puppet master in UEC === ---- CategorySpec