# SOME DESCRIPTIVE TITLE. # Copyright (C) 2015, OpenStack contributors # This file is distributed under the same license as the FirstApp package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: FirstApp 0.1\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2015-10-22 06:04+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../advice.rst:3 msgid "Advice for developers new to operations" msgstr "" #: ../advice.rst:5 msgid "" "In this section, we will introduce some operational concepts and tasks which " "may be new to developers who have not written cloud applications before." msgstr "" #: ../advice.rst:10 msgid "Monitoring" msgstr "" #: ../advice.rst:12 msgid "" "Monitoring is essential for cloud applications, especially if the " "application is to be 'scalable'. You must know how many requests are coming " "in, and what impact that has on the various services -- in other words, " "enough information to determine whether you should start another worker or " "API service as we did in :doc:`/scaling_out`." msgstr "" #: ../advice.rst:21 msgid "" "Aside from this kind of monitoring, you should consider availability " "monitoring. Does your application care about a worker going down? Maybe " "not. Does it care about a failed database server? Probably yes." msgstr "" #: ../advice.rst:25 msgid "" "One great pattern to add this to your application is the `Health Endpoint " "Monitoring Pattern `, where a special API endpoint is introduced to your application for a " "basic health check." msgstr "" #: ../advice.rst:32 msgid "Backups" msgstr "" #: ../advice.rst:34 msgid "" "Where instances store information that is not reproducible (such as a " "database server, a file server, or even log files for an application), it is " "important to back up this information as you would a normal non-cloud " "server. It sounds simple, but just because it is 'in the cloud' does not " "mean it has any additional robustness or resilience when it comes to failure " "of the underlying hardware or systems." msgstr "" #: ../advice.rst:41 msgid "" "OpenStack provides a couple of tools that make it easier to perform backups. " "If your provider runs OpenStack Object Storage, this is normally extremely " "robust and has several handy API calls and CLI tools for working with " "archive files." msgstr "" #: ../advice.rst:46 msgid "" "It is also possible to create snapshots of running instances and persistent " "volumes using the OpenStack API. Refer to the documentation of your SDK for " "more." msgstr "" #: ../advice.rst:53 msgid "" "While the technical action to perform backups can be straightforward, you " "should also think about your policies regarding what is backed up and how " "long each item should be retained." msgstr "" #: ../advice.rst:58 msgid "Phoenix Servers" msgstr "" #: ../advice.rst:60 msgid "" "Application developers and operators who employ `Phoenix Servers `_ have built systems that start " "from a known baseline (sometimes just a specific version of an operating " "system) and have built tooling that will automatically build, install, and " "configure a system with no manual intervention." msgstr "" #: ../advice.rst:66 msgid "" "Phoenix Servers, named for the mythological bird that would live its life, " "be consumed by fire, then rise from the ashes to live again, make it " "possible to easily \"start over\" with new instances." msgstr "" #: ../advice.rst:70 msgid "" "If your application is automatically deployed on a regular basis, resolving " "outages and security updates are not special operations that require manual " "intervention. If you suffer an outage, provision more resources in another " "region. If you have to patch security holes, provision more compute nodes " "that will be built with the updated/patched software, then terminate " "vulnerable nodes, with traffic automatically failing over to the new " "instances." msgstr "" #: ../advice.rst:79 msgid "Security" msgstr "" #: ../advice.rst:81 msgid "" "Security-wise, one thing to keep in mind is that if one instance of an " "application is compromised, all instances with the same image and " "configuration are likely to suffer the same vulnerability. In this case, it " "is safer to rebuild all of your instances (a task made easier by " "configuration management - see below)." msgstr "" #: ../advice.rst:88 msgid "Configuration management" msgstr "" #: ../advice.rst:90 msgid "" "Tools such as Ansible, Chef, and Puppet allow you to describe exactly what " "should be installed on an instance and how it should be configured. Using " "these descriptions, the tool implements any changes required to get to the " "desired state." msgstr "" #: ../advice.rst:95 msgid "" "These tools vastly reduce the amount of effort it takes to work with large " "numbers of servers, and also improves the ability to recreate, update, move, " "or distribute applications." msgstr "" #: ../advice.rst:100 msgid "Application deployment" msgstr "" #: ../advice.rst:102 msgid "" "Related to configuration management is the question of how you deploy your " "application." msgstr "" #: ../advice.rst:105 msgid "For example, do you:" msgstr "" #: ../advice.rst:107 msgid "pull the latest code from a source control repository?" msgstr "" #: ../advice.rst:108 msgid "make packaged releases that update infrequently?" msgstr "" #: ../advice.rst:109 msgid "" "big-bang test in a development environment and deploy only after major " "changes?" msgstr "" #: ../advice.rst:112 msgid "" "One of the latest trends in deploying scalable cloud applications is " "`continuous integration `_ / `continuous deployment `_ (CI/CD). Working in a CI/CD fashion means you " "are always testing your application and making frequent deployments to " "production." msgstr "" #: ../advice.rst:119 msgid "" "In this tutorial, we have downloaded the latest version of our application " "from source and installed it on a standard image. Our magic install script " "also updates the standard image to have the latest dependencies we need to " "run the application." msgstr "" #: ../advice.rst:124 msgid "" "Another approach to this is to create a 'gold' image - one that has your " "application and dependencies pre-installed. This means faster boot times and " "a higher degree of control over what is on the instance, however a process " "is needed to ensure that 'gold' images do not fall behind on security " "updates." msgstr "" #: ../advice.rst:130 msgid "Fail fast" msgstr "" #: ../appendix.rst:3 msgid "Appendix" msgstr "" #: ../appendix.rst:6 msgid "Bootstrapping your network" msgstr "" #: ../appendix.rst:8 msgid "" "Most cloud providers will provision all of the required network objects " "necessary to boot an instance. An easy way to see if these have been " "created for you is to access the Network Topology section of the OpenStack " "dashboard." msgstr "" #: ../appendix.rst:21 msgid "Specify a network during instance build" msgstr "" #: ../block_storage.rst:3 msgid "Block Storage" msgstr "" #: ../block_storage.rst:8 msgid "" "By default, data in OpenStack instances is stored on 'ephemeral' disks. " "These disks stay with the instance throughout its lifetime, but when the " "instance is terminated, that storage and all the data stored on it " "disappears. Ephemeral storage is allocated to a single instance and cannot " "be moved to another instance." msgstr "" #: ../block_storage.rst:14 msgid "" "This section introduces block storage, also known as volume storage, which " "provides access to persistent storage devices. You interact with block " "storage by attaching volumes to running instances just as you might attach a " "USB drive to a physical server. You can detach volumes from one instance and " "reattach them to another instance and the data remains intact. The OpenStack " "Block Storage (cinder) project implements block storage." msgstr "" #: ../block_storage.rst:21 msgid "" "Though you might have configured Object Storage to store images, the Fractal " "application needs a database to track the location of and parameters that " "were used to create images in Object Storage. This database server cannot " "fail." msgstr "" #: ../block_storage.rst:25 msgid "" "If you are an advanced user, consider how you might remove the database from " "the architecture and replace it with Object Storage metadata (then " "contribute these steps to :doc:`craziness`). Other users can continue " "reading to learn how to work with block storage and move the Fractal " "application database server to use it." msgstr "" #: ../block_storage.rst:32 msgid "Basics" msgstr "" #: ../block_storage.rst:34 msgid "" "Later on, we'll use a Block Storage volume to provide persistent storage for " "the database server for the Fractal application. But first, learn how to " "create and attach a Block Storage device." msgstr "" #: ../block_storage.rst:40 ../durability.rst:77 ../introduction.rst:13 msgid "This section has not yet been completed for the .NET SDK." msgstr "" #: ../block_storage.rst:44 ../durability.rst:81 ../introduction.rst:17 msgid "This section has not yet been completed for the fog SDK." msgstr "" #: ../block_storage.rst:52 ../durability.rst:111 ../introduction.rst:25 msgid "This section has not yet been completed for the pkgcloud SDK." msgstr "" #: ../block_storage.rst:64 msgid "As always, connect to the API endpoint:" msgstr "" #: ../block_storage.rst:94 msgid "To try it out, make a 1GB volume called :test'." msgstr "" #: ../block_storage.rst:114 msgid "The parameter :code:`size` is in gigabytes." msgstr "" #: ../block_storage.rst:116 msgid "List all volumes to see if it was successful:" msgstr "" #: ../block_storage.rst:136 msgid "Attach the storage volume to a running instance." msgstr "" #: ../block_storage.rst:139 msgid "Use Block Storage for the Fractal database server" msgstr "" #: ../block_storage.rst:141 msgid "" "You need a server for the dedicated database. Use the image, flavor, and " "keypair that you used in :doc:`/getting_started` to launch an :code:`app-" "database` instance." msgstr "" #: ../block_storage.rst:145 msgid "" "You also need a security group to permit access to the database server (for " "MySQL, port 3306) from the network:" msgstr "" #: ../block_storage.rst:167 msgid "" "Create a volume object by using the unique identifier (UUID) for the volume. " "Then, use the server object from the previous code snippet to attach the " "volume to it at :code:`/dev/vdb`:" msgstr "" #: ../block_storage.rst:185 msgid "Log in to the server to run the following steps." msgstr "" #: ../block_storage.rst:187 msgid "" "Replace :code:`IP_SERVICES` with the IP address of the services instance and " "USERNAME to the appropriate user name." msgstr "" #: ../block_storage.rst:190 msgid "Now prepare the empty block device." msgstr "" #: ../block_storage.rst:202 msgid "" "Stop the running MySQL database service and move the database files from :" "file:`/var/lib/mysql` to the new volume, which is temporarily mounted at :" "file:`/mnt/database`." msgstr "" #: ../block_storage.rst:211 msgid "" "Sync the file systems and mount the block device that contains the database " "files to :file:`/var/lib/mysql`." msgstr "" #: ../block_storage.rst:222 msgid "" "Finally, start the stopped MySQL database service and validate that " "everything works as expected." msgstr "" #: ../block_storage.rst:231 msgid "Extras" msgstr "" #: ../block_storage.rst:233 msgid "" "You can detach the volume and reattach it elsewhere, or use the following " "steps to destroy the volume." msgstr "" #: ../block_storage.rst:237 msgid "The following operations are destructive and result in data loss." msgstr "" #: ../block_storage.rst:239 msgid "To detach and destroy a volume:" msgstr "" #: ../block_storage.rst:255 msgid "" ":code:`detach_volume` and :code:`destroy_volume` take a volume object, not a " "name." msgstr "" #: ../block_storage.rst:267 msgid "" "Other features, such as creating volume snapshots, are useful for backups:" msgstr "" #: ../block_storage.rst:277 msgid "" "For information about these and other calls, see `libcloud documentation " "`_." msgstr "" #: ../block_storage.rst:282 msgid "Work with the OpenStack Database service" msgstr "" #: ../block_storage.rst:284 msgid "" "Previously, you manually created the database, which is useful for a a " "single database that you rarely update. However, the OpenStack :code:`trove` " "component provides Database as a Service (DBaaS)." msgstr "" #: ../block_storage.rst:288 msgid "" "This OpenStack Database service is not installed in many clouds right now, " "but if your cloud supports it, it can make your life a lot easier when " "working with databases." msgstr "" #: ../block_storage.rst:292 msgid "" "SDKs do not generally support the service yet, but you can use the 'trove' " "command-line client to work with it instead." msgstr "" #: ../block_storage.rst:295 msgid "" "Install the trove command-line client by following this guide: http://docs." "openstack.org/cli-reference/content/install_clients.html" msgstr "" #: ../block_storage.rst:298 msgid "" "Then, set up necessary variables for your cloud in an :file:`openrc.sh` file " "by using this guide: http://docs.openstack.org/cli-reference/content/" "cli_openrc.html" msgstr "" #: ../block_storage.rst:302 msgid "" "Ensure you have an :file:`openrc.sh` file, source it, and validate that your " "trove client works: ::" msgstr "" #: ../block_storage.rst:317 msgid "" "For information about supported features and how to work with an existing " "database service installation, see these `slides `_." msgstr "" #: ../block_storage.rst:322 ../craziness.rst:67 ../durability.rst:317 #: ../getting_started.rst:1222 ../introduction.rst:631 ../networking.rst:795 #: ../scaling_out.rst:408 msgid "Next steps" msgstr "" #: ../block_storage.rst:324 msgid "" "You should now be fairly confident working with Block Storage volumes. For " "information about other calls, see the volume documentation for your SDK or " "try one of these tutorial steps:" msgstr "" #: ../block_storage.rst:328 ../durability.rst:330 msgid ":doc:`/orchestration`: to automatically orchestrate the application" msgstr "" #: ../block_storage.rst:329 ../durability.rst:331 msgid ":doc:`/networking`: to learn about more complex networking" msgstr "" #: ../block_storage.rst:330 ../durability.rst:332 ../networking.rst:802 msgid ":doc:`/advice`: for advice for developers new to operations" msgstr "" #: ../craziness.rst:3 msgid "Going crazy" msgstr "" #: ../craziness.rst:5 msgid "This section explores options for expanding the sample application." msgstr "" #: ../craziness.rst:8 msgid "Regions and geographic diversity" msgstr "" #: ../craziness.rst:10 msgid "" "For more information about multi-site clouds, see the `Multi-Site chapter " "`_ in the " "Architecture Design Guide." msgstr "" #: ../craziness.rst:15 msgid "" "OpenStack supports 'regions', which are geographically-separated " "installations that are connected to a single service catalog. This section " "explains how to expand the Fractal application to use multiple regions for " "high availability." msgstr "" #: ../craziness.rst:19 ../craziness.rst:32 ../craziness.rst:39 #: ../craziness.rst:64 msgid "This section is incomplete. Please help us finish it!" msgstr "" #: ../craziness.rst:22 msgid "Multiple clouds" msgstr "" #: ../craziness.rst:24 msgid "" "For more information about hybrid clouds, see the `Hybrid Cloud chapter " "`_ in the " "Architecture Design Guide." msgstr "" #: ../craziness.rst:29 msgid "" "You might want to use multiple clouds such as a private cloud inside your " "organization and a public cloud. This section attempts to do exactly that." msgstr "" #: ../craziness.rst:35 msgid "High availability" msgstr "" #: ../craziness.rst:37 msgid "Using Pacemaker to look at the API." msgstr "" #: ../craziness.rst:42 msgid "conf.d, etc.d" msgstr "" #: ../craziness.rst:44 msgid "Use conf.d and etc.d." msgstr "" #: ../craziness.rst:46 msgid "" "In earlier sections, the Fractal application used an installation script " "into which the metadata API passed parameters to bootstrap the cluster. " "`Etcd `_ is \"a distributed, consistent key-" "value store for shared configuration and service discovery\" that you can " "use to store configurations. You can write updated versions of the Fractal " "worker component to connect to Etcd or use `Confd `_ to poll for changes from Etcd and write changes to " "a configuration file on the local file system, which the Fractal worker can " "use for configuration." msgstr "" #: ../craziness.rst:57 msgid "Using Object Storage instead of a database" msgstr "" #: ../craziness.rst:59 msgid "" "We haven't quite figured out how to do this yet, but the general steps " "involve changing the fractal upload code to store metadata with the object " "in swift, then changing the API code such as \"list fractals\" to query " "swift to get the metadata. If you do this, you should be able to stop using " "a database." msgstr "" #: ../craziness.rst:69 msgid "" "Wow! If you've made it through this section, you know more than the authors " "of this guide know about working with OpenStack clouds." msgstr "" #: ../craziness.rst:72 msgid "" "Perhaps you can `contribute `_?" msgstr "" #: ../durability.rst:3 msgid "Making it durable" msgstr "" #: ../durability.rst:14 msgid "" "This section introduces object storage. `OpenStack Object Storage `_ (code-named swift) is open " "source software for creating redundant, scalable data storage using clusters " "of standardized servers to store petabytes of accessible data. It is a long-" "term storage system for large amounts of static data that can be retrieved, " "leveraged, and updated. Access is via an API, not through a file-system like " "more traditional storage." msgstr "" #: ../durability.rst:23 msgid "" "There are a two key concepts to understand in the Object Storage API. The " "Object Storage API is organized around two types of entities:" msgstr "" #: ../durability.rst:26 msgid "Objects" msgstr "" #: ../durability.rst:27 msgid "Containers" msgstr "" #: ../durability.rst:29 msgid "" "Similar to the Unix programming model, an object is a \"bag of bytes\" that " "contains data, such as documents and images. Containers are used to group " "objects. You can make many objects inside a container, and have many " "containers inside your account." msgstr "" #: ../durability.rst:34 msgid "" "If you think about how you traditionally make what you store durable, very " "quickly you should come to the conclusion that keeping multiple copies of " "your objects on separate systems is a good way to do that. However, keeping " "track of multiple copies of objects is a pain, and building that into an app " "requires a lot of logic. OpenStack Object Storage does this automatically " "for you behind-the-scenes - replicating each object at least twice before " "returning 'write success' to your API call. It will always work to ensure " "that there are three copies of your objects (by default) at all times - " "replicating them around the system in case of hardware failure, maintenance, " "network outage or any other kind of breakage. This is very convenient for " "app creation - you can just dump objects into object storage and not have to " "care about any of this additional work to keep them safe." msgstr "" #: ../durability.rst:51 msgid "Using Object Storage to store fractals" msgstr "" #: ../durability.rst:53 msgid "" "The Fractals app currently uses the local filesystem on the instance to " "store the images it generates. This is not scalable or durable, for a number " "of reasons." msgstr "" #: ../durability.rst:57 msgid "" "Because the local filesystem is ephemeral storage, if the instance is " "terminated, the fractal images will be lost along with the instance. Block " "based storage, which we'll discuss in :doc:`/block_storage`, avoids that " "problem, but like local filesystems, it requires administration to ensure " "that it does not fill up, and immediate attention if disks fail." msgstr "" #: ../durability.rst:64 msgid "" "The Object Storage service manages many of these tasks that normally would " "require the application owner to manage them, and presents a scalable and " "durable API that you can use for the fractals app, without having to be " "concerned with the low level details of how the objects are stored and " "replicated, and growing the storage pool. In fact, Object Storage handles " "replication intrinsically, storing multiple copies of each object and " "returning one of them on demand using the API." msgstr "" #: ../durability.rst:73 msgid "First, let's learn how to connect to the Object Storage endpoint:" msgstr "" #: ../durability.rst:96 msgid "" "Libcloud 0.16 and 0.17 are afflicted with a bug that means authentication to " "a swift endpoint can fail with `a Python exception `_. If you encounter this, you can upgrade " "your libcloud version, or apply a simple `2-line patch `_." msgstr "" #: ../durability.rst:104 msgid "" "Libcloud uses a different connector for Object Storage to all other " "OpenStack services, so a conn object from previous sections won't work here " "and we have to create a new one named :code:`swift`." msgstr "" #: ../durability.rst:123 msgid "" "To begin to store objects, we must first make a container. Call yours :code:" "`fractals`:" msgstr "" #: ../durability.rst:132 ../durability.rst:147 msgid "You should see output such as:" msgstr "" #: ../durability.rst:138 msgid "" "You should now be able to see this container appear in a listing of all " "containers in your account:" msgstr "" #: ../durability.rst:153 msgid "" "The next logical step is to upload an object. Find a photo of a goat online, " "name it :code:`goat.jpg` and upload it to your container :code:`fractals`:" msgstr "" #: ../durability.rst:163 msgid "" "List objects in your container :code:`fractals` to see if the upload was " "successful, then download the file to verify the md5sum is the same:" msgstr "" #: ../durability.rst:196 msgid "Finally, let's clean up by deleting our test object:" msgstr "" #: ../durability.rst:204 msgid "You need to pass in objects to the delete commands, not object names." msgstr "" #: ../durability.rst:206 msgid "" "Now there should be no more objects be available in the container :code:" "`fractals`." msgstr "" #: ../durability.rst:217 msgid "Backup the Fractals from the database on the Object Storage" msgstr "" #: ../durability.rst:219 msgid "" "So let's now use the knowledge from above to backup the images of the " "Fractals app, stored inside the database right now, on the Object Storage." msgstr "" #: ../durability.rst:223 msgid "Use the :code:`fractals`' container from above to put the images in:" msgstr "" #: ../durability.rst:231 msgid "" "Next, we backup all of our existing fractals from the database to our swift " "container. A simple for loop takes care of that:" msgstr "" #: ../durability.rst:246 msgid "Replace :code:`IP_API_1` with the IP address of the API instance." msgstr "" #: ../durability.rst:248 msgid "" "The example code uses the awesome `Requests library `_. Ensure that it is installed on your system " "before trying to run the script above." msgstr "" #: ../durability.rst:252 msgid "Configure the Fractals app to use Object Storage" msgstr "" #: ../durability.rst:254 msgid "" "Currently it is not possible to directly store generated images on the " "OpenStack Object Storage. Please revisit this section again in the future." msgstr "" #: ../durability.rst:259 msgid "Extra features" msgstr "" #: ../durability.rst:262 msgid "Delete containers" msgstr "" #: ../durability.rst:264 msgid "" "One call we didn't cover above that you probably need to know is how to " "delete a container. Ensure that you have removed all objects from the " "container before running this, otherwise it will fail:" msgstr "" #: ../durability.rst:274 msgid "It is not possible to restore deleted objects. Be careful." msgstr "" #: ../durability.rst:277 msgid "Add metadata to objects" msgstr "" #: ../durability.rst:279 msgid "" "You can also do advanced things like uploading an object with metadata, such " "as in this below example, but for further information we'll refer you to the " "documentation for your SDK. This option also uses a bit stream to upload the " "file - iterating bit by bit over the file and passing those bits to swift as " "they come, compared to loading the entire file in memory and then sending " "it. This is more efficient, especially for larger files." msgstr "" #: ../durability.rst:296 msgid "Large objects" msgstr "" #: ../durability.rst:298 msgid "" "For efficiency, most Object Storage installations treat large objects (say, :" "code:`> 5GB`) differently than smaller objects." msgstr "" #: ../durability.rst:303 msgid "" "If you are working with large objects, use the :code:" "`ex_multipart_upload_object` call instead of the simpler :code:" "`upload_object` call. How the upload works behind-the-scenes is by splitting " "the large object into chunks, and creating a special manifest so they can be " "recombined on download. Alter the :code:`chunk_size` parameter (in bytes) " "according to what your cloud can accept." msgstr "" #: ../durability.rst:319 msgid "" "You should now be fairly confident working with Object Storage. You can find " "more about the Object Storage SDK calls at:" msgstr "" #: ../durability.rst:324 msgid "https://libcloud.readthedocs.org/en/latest/storage/api.html" msgstr "" #: ../durability.rst:326 msgid "Or try a different step in the tutorial, including:" msgstr "" #: ../durability.rst:328 msgid "" ":doc:`/block_storage`: to migrate the database to block storage, or use the " "database-as-as-service component" msgstr "" #: ../getting_started.rst:3 msgid "Getting started" msgstr "" #: ../getting_started.rst:6 msgid "Who should read this guide" msgstr "" #: ../getting_started.rst:8 msgid "" "This guide is for software developers who want to deploy applications to " "OpenStack clouds." msgstr "" #: ../getting_started.rst:11 msgid "" "We assume that you're an experienced programmer who has not created a cloud " "application in general or an OpenStack application in particular." msgstr "" #: ../getting_started.rst:14 msgid "" "If you're familiar with OpenStack, this section teaches you how to program " "with its components." msgstr "" #: ../getting_started.rst:18 msgid "What you will learn" msgstr "" #: ../getting_started.rst:20 msgid "" "Deploying applications in a cloud environment can be very different from " "deploying them in a traditional IT environment. This guide teaches you how " "to deploy applications on OpenStack and some best practices for cloud " "application development." msgstr "" #: ../getting_started.rst:26 msgid "A general overview" msgstr "" #: ../getting_started.rst:28 msgid "" "This tutorial shows two applications. The first application is a simple " "fractal generator that uses mathematical equations to generate beautiful " "`fractal images `_. We show you this " "application in its entirety so that you can compare it to a second, more " "robust, application." msgstr "" #: ../getting_started.rst:34 msgid "The second application is an OpenStack application that enables you to:" msgstr "" #: ../getting_started.rst:36 msgid "" "Create and destroy compute resources. These resources are virtual machine " "instances where the Fractals application runs." msgstr "" #: ../getting_started.rst:38 msgid "" "Make cloud-related architecture decisions such as turning functions into " "micro-services and modularizing them." msgstr "" #: ../getting_started.rst:40 msgid "Scale available resources up and down." msgstr "" #: ../getting_started.rst:41 msgid "Use Object and Block storage for file and database persistence." msgstr "" #: ../getting_started.rst:42 msgid "Use Orchestration services to automatically adjust to the environment." msgstr "" #: ../getting_started.rst:43 msgid "Customize networking for better performance and segregation." msgstr "" #: ../getting_started.rst:44 msgid "Explore and apply advanced OpenStack cloud features." msgstr "" #: ../getting_started.rst:47 msgid "Choose your OpenStack SDK" msgstr "" #: ../getting_started.rst:49 msgid "" "Anyone with a programming background can easily read the code in this guide. " "Although this guide focuses on a particular SDK, you can use other languages " "and toolkits with the OpenStack cloud:" msgstr "" #: ../getting_started.rst:54 ../introduction.rst:455 ../introduction.rst:508 msgid "Description" msgstr "" #: ../getting_started.rst:54 msgid "Language" msgstr "" #: ../getting_started.rst:54 msgid "Name" msgstr "" #: ../getting_started.rst:54 msgid "URL" msgstr "" #: ../getting_started.rst:56 msgid "" "A Python-based library managed by the Apache Foundation. This library " "enables you to work with multiple types of clouds." msgstr "" #: ../getting_started.rst:56 msgid "Libcloud" msgstr "" #: ../getting_started.rst:56 ../getting_started.rst:58 #: ../getting_started.rst:59 msgid "Python" msgstr "" #: ../getting_started.rst:57 msgid "https://libcloud.apache.org" msgstr "" #: ../getting_started.rst:58 msgid "A Python-based library specifically developed for OpenStack." msgstr "" #: ../getting_started.rst:58 msgid "OpenStack SDK" msgstr "" #: ../getting_started.rst:58 msgid "http://git.openstack.org/cgit/openstack/python-openstacksdk" msgstr "" #: ../getting_started.rst:59 msgid "" "A Python-based library developed by OpenStack Infra team to operate multiple " "OpenStack clouds." msgstr "" #: ../getting_started.rst:59 msgid "Shade" msgstr "" #: ../getting_started.rst:59 msgid "http://git.openstack.org/cgit/openstack-infra/shade" msgstr "" #: ../getting_started.rst:61 msgid "" "A Java-based library. Like Libcloud, it's also managed by the Apache " "Foundation and works with multiple types of clouds." msgstr "" #: ../getting_started.rst:61 msgid "Java" msgstr "" #: ../getting_started.rst:61 msgid "https://jclouds.apache.org" msgstr "" #: ../getting_started.rst:61 msgid "jClouds" msgstr "" #: ../getting_started.rst:63 msgid "A Ruby-based SDK for multiple clouds." msgstr "" #: ../getting_started.rst:63 msgid "Ruby" msgstr "" #: ../getting_started.rst:63 msgid "fog" msgstr "" #: ../getting_started.rst:63 msgid "" "https://github.com/fog/fog/blob/master/lib/fog/openstack/docs/" "getting_started.md" msgstr "" #: ../getting_started.rst:64 msgid "A Node.js-based SDK for multiple clouds." msgstr "" #: ../getting_started.rst:64 msgid "https://github.com/pkgcloud/pkgcloud" msgstr "" #: ../getting_started.rst:64 msgid "node.js" msgstr "" #: ../getting_started.rst:64 msgid "pkgcloud" msgstr "" #: ../getting_started.rst:65 msgid "A library for developers using PHP to work with OpenStack clouds." msgstr "" #: ../getting_started.rst:65 msgid "PHP" msgstr "" #: ../getting_started.rst:65 msgid "http://php-opencloud.com/" msgstr "" #: ../getting_started.rst:65 msgid "php-opencloud" msgstr "" #: ../getting_started.rst:66 msgid ".NET Framework" msgstr "" #: ../getting_started.rst:66 msgid "" "A .NET-based library enables you to write C++ or C# code for Microsoft " "applications." msgstr "" #: ../getting_started.rst:66 msgid "OpenStack SDK for Microsoft .NET" msgstr "" #: ../getting_started.rst:66 msgid "https://www.nuget.org/packages/openstack.net" msgstr "" #: ../getting_started.rst:71 msgid "" "For a list of available SDKs, see `Software Development Kits `_." msgstr "" #: ../getting_started.rst:73 msgid "" "Other versions of this guide show you how to use the other SDKs and " "languages to complete these tasks. If you're a developer for another toolkit " "that you would like this guide to include, feel free to submit code " "snippets. You can contact `OpenStack Documentation team `_ members for more information." msgstr "" #: ../getting_started.rst:80 msgid "What you need" msgstr "" #: ../getting_started.rst:82 msgid "" "We assume that you can already access an OpenStack cloud. You must have a " "project, also known as a tenant, with a minimum quota of six instances. " "Because the Fractals application runs in Ubuntu, Debian, Fedora-based, and " "openSUSE-based distributions, you must create instances that use one of " "these operating systems." msgstr "" #: ../getting_started.rst:88 msgid "To interact with the cloud, you must also have" msgstr "" #: ../getting_started.rst:92 msgid "" "`OpenStack Cloud SDK for Microsoft .NET 1.4.0.1 or later installed `_." msgstr "" #: ../getting_started.rst:97 msgid "" "To install the OpenStack .NET SDK, use the NeGet Package Manager that is " "included with Visual Studio and Xamarin Studio. You simply add a package " "named 'openstack.net' and the NeGet Package Manager automatically installs " "the necessary dependencies." msgstr "" #: ../getting_started.rst:104 msgid "This document has not yet been completed for the .NET SDK." msgstr "" #: ../getting_started.rst:108 msgid "" "`fog 1.19 or higher installed `_ and working with ruby gems 1.9." msgstr "" #: ../getting_started.rst:114 msgid "This document has not yet been completed for the fog SDK." msgstr "" #: ../getting_started.rst:126 msgid "" "`libcloud 0.15.1 or higher installed `_." msgstr "" #: ../getting_started.rst:131 msgid "" "`pkgcloud 1.2 or higher installed `_." msgstr "" #: ../getting_started.rst:154 msgid "" "`a recent version of shade library installed `_." msgstr "" #: ../getting_started.rst:156 msgid "Before proceeding, install the latest version of shade." msgstr "" #: ../getting_started.rst:158 msgid "Obtain the following information from your cloud provider:" msgstr "" #: ../getting_started.rst:160 msgid "auth URL" msgstr "" #: ../getting_started.rst:161 msgid "user name" msgstr "" #: ../getting_started.rst:162 msgid "password" msgstr "" #: ../getting_started.rst:163 msgid "project ID or name (projects are also known as tenants)" msgstr "" #: ../getting_started.rst:164 msgid "cloud region" msgstr "" #: ../getting_started.rst:166 msgid "" "You can also download the OpenStack RC file from the OpenStack Horizon " "dashboard. Log in to the dashboard and click :guilabel:`Project->Access & " "Security->API Access->Download OpenStack RC file`. If you use this method, " "be aware that the \"auth URL\" does not include the path. For example, if " "your :file:`openrc.sh` file shows:" msgstr "" #: ../getting_started.rst:176 msgid "The actual auth URL is:" msgstr "" #: ../getting_started.rst:183 msgid "How you'll interact with OpenStack" msgstr "" #: ../getting_started.rst:185 msgid "" "In this tutorial, you interact with your OpenStack cloud through the SDK " "that you chose in \"Choose your OpenStack SDK.\" This guide assumes that you " "know how to run code snippets in your language of choice." msgstr "" #: ../getting_started.rst:198 msgid "" "To try it, add the following code to a Python script (or use an interactive " "Python shell) by calling :code:`python -i`." msgstr "" #: ../getting_started.rst:216 msgid "" "To try it, add the following code to a script (or use an interactive nodejs " "shell) by calling :code:`node`." msgstr "" #: ../getting_started.rst:225 msgid "" "To use the OpenStack .NET SDK, add the following code in the required " "namespace section." msgstr "" #: ../getting_started.rst:234 msgid "" "Because all service endpoints use the Identity Service for authentication " "and authorization, place the following code in the 'void Main()' entry-point " "function." msgstr "" #: ../getting_started.rst:245 msgid "" "Because the tutorial reuses the :code:`conn` object, make sure that you " "always have one handy." msgstr "" #: ../getting_started.rst:250 msgid "" "If you receive the :code:`libcloud.common.types.InvalidCredsError: 'Invalid " "credentials with the provider'` exception when you run one of these API " "calls, double-check your credentials." msgstr "" #: ../getting_started.rst:255 msgid "" "If your provider does not support regions, try a blank string ('') for the " "`region_name`." msgstr "" #: ../getting_started.rst:260 msgid "" "Use your credentials above to specify the cloud provider name, user name, " "password, project_name and region_name in the file :file:`~/.config/" "openstack/clouds.yml`." msgstr "" #: ../getting_started.rst:267 msgid "" "If you do use a public cloud `known by shade `_, you can avoid " "specifying :code:`auth_url:` and instead specify :code:`profile: " "$PROVIDER_NAME` in the clouds.yml file." msgstr "" #: ../getting_started.rst:277 msgid "Flavors and images" msgstr "" #: ../getting_started.rst:279 msgid "" "To run your application, you must launch an instance. This instance serves " "as a virtual machine." msgstr "" #: ../getting_started.rst:282 msgid "" "To launch an instance, you choose a flavor and an image. The flavor " "represents the size of the instance, including the number of CPUs and amount " "of RAM and disk space. An image is a prepared OS installation from which you " "clone your instance. When you boot instances in a public cloud, larger " "flavors can be more expensive than smaller ones in terms of resources and " "monetary cost." msgstr "" #: ../getting_started.rst:288 msgid "" "To list the images that are available in your cloud, run some API calls:" msgstr "" #: ../getting_started.rst:303 ../getting_started.rst:316 #: ../getting_started.rst:341 ../getting_started.rst:357 #: ../getting_started.rst:397 ../getting_started.rst:413 #: ../getting_started.rst:438 ../getting_started.rst:457 #: ../getting_started.rst:515 ../getting_started.rst:527 #: ../getting_started.rst:545 ../getting_started.rst:557 #: ../getting_started.rst:597 ../getting_started.rst:609 #: ../getting_started.rst:628 ../getting_started.rst:643 #: ../getting_started.rst:700 ../getting_started.rst:723 #: ../getting_started.rst:737 msgid "This code returns output like this:" msgstr "" #: ../getting_started.rst:382 msgid "You can also get information about available flavors:" msgstr "" #: ../getting_started.rst:483 msgid "Your images and flavors will be different, of course." msgstr "" #: ../getting_started.rst:485 msgid "" "Choose an image and flavor for your instance. You need about 1GB RAM, 1 CPU, " "and a 1GB disk. This example uses the Ubuntu image with a small flavor, " "which is a safe choice. In subsequent tutorial sections in this guide, you " "must change the image and flavor IDs to correspond to the image and flavor " "that you choose." msgstr "" #: ../getting_started.rst:491 msgid "" "If the image that you want is not available in your cloud, you can usually " "upload one depending on your cloud's policy settings. For information about " "how to upload images, see `obtaining images `_." msgstr "" #: ../getting_started.rst:496 msgid "" "Set the image and size variables to appropriate values for your cloud. We'll " "use these variables in later sections." msgstr "" #: ../getting_started.rst:499 msgid "" "First, tell the connection to get a specified image by using the ID of the " "image that you picked in the previous section:" msgstr "" #: ../getting_started.rst:582 msgid "Next, choose which flavor you want to use:" msgstr "" #: ../getting_started.rst:636 msgid "" "Because shade accepts either the ID or name in most API calls, specify the " "name for the flavor:" msgstr "" #: ../getting_started.rst:669 msgid "Now, you're ready to launch the instance." msgstr "" #: ../getting_started.rst:672 msgid "Launch an instance" msgstr "" #: ../getting_started.rst:674 msgid "Use your selected image and flavor to create an instance." msgstr "" #: ../getting_started.rst:676 msgid "" "The following instance creation example assumes that you have a single-" "tenant network. If you receive the 'Exception: 400 Bad Request Multiple " "possible networks found, use a Network ID to be more specific' error, you " "have multiple-tenant networks. You must add a `networks` parameter to the " "call that creates the server. See :doc:`/appendix` for details." msgstr "" #: ../getting_started.rst:683 msgid "Create the instance." msgstr "" #: ../getting_started.rst:685 msgid "Your SDK might call an instance a 'node' or 'server'." msgstr "" #: ../getting_started.rst:749 msgid "If you list existing instances:" msgstr "" #: ../getting_started.rst:785 msgid "The new instance appears." msgstr "" #: ../getting_started.rst:891 msgid "Before you continue, you must do one more thing." msgstr "" #: ../getting_started.rst:894 msgid "Destroy an instance" msgstr "" #: ../getting_started.rst:896 msgid "" "Cloud resources such as running instances that you no longer use can cost " "money. Destroy cloud resources to avoid unexpected expenses." msgstr "" #: ../getting_started.rst:932 msgid "If you list the instances again, the instance disappears." msgstr "" #: ../getting_started.rst:934 msgid "" "Leave your shell open to use it for another instance deployment in this " "section." msgstr "" #: ../getting_started.rst:938 msgid "Deploy the application to a new instance" msgstr "" #: ../getting_started.rst:940 msgid "" "Now that you know how to create and destroy instances, you can deploy the " "sample application. The instance that you create for the application is " "similar to the first instance that you created, but this time, we'll briefly " "introduce a few extra concepts." msgstr "" #: ../getting_started.rst:945 msgid "" "Internet connectivity from your cloud instance is required to download the " "application." msgstr "" #: ../getting_started.rst:948 msgid "" "When you create an instance for the application, you'll want to give it a " "bit more information than you supplied to the bare instance that you just " "created and destroyed. We'll go into more detail in later sections, but for " "now, simply create the following resources so that you can feed them to the " "instance:" msgstr "" #: ../getting_started.rst:954 msgid "" "A key pair. To access your instance, you must import an SSH public key into " "OpenStack to create a key pair. OpenStack installs this key pair on the new " "instance. Typically, your public key is written to :code:`.ssh/id_rsa.pub`. " "If you do not have an SSH public key file, follow `these instructions " "`_ first. We'll " "cover these instructions in depth in :doc:`/introduction`." msgstr "" #: ../getting_started.rst:963 ../getting_started.rst:974 #: ../getting_started.rst:987 ../getting_started.rst:996 msgid "" "In the following example, :code:`pub_key_file` should be set to the location " "of your public SSH key file." msgstr "" #: ../getting_started.rst:1004 msgid "" "Network access. By default, OpenStack filters all traffic. You must create a " "security group and apply it to your instance. The security group allows HTTP " "and SSH access. We'll go into more detail in :doc:`/introduction`." msgstr "" #: ../getting_started.rst:1033 msgid "" "User data. During instance creation, you can provide user data to OpenStack " "to configure instances after they boot. The cloud-init service applies the " "user data to an instance. You must pre-install the cloud-init service on " "your chosen image. We'll go into more detail in :doc:`/introduction`." msgstr "" #: ../getting_started.rst:1063 msgid "Now, you can boot and configure the instance." msgstr "" #: ../getting_started.rst:1066 msgid "Boot and configure an instance" msgstr "" #: ../getting_started.rst:1068 msgid "" "Use the image, flavor, key pair, and userdata to create an instance. After " "you request the instance, wait for it to build." msgstr "" #: ../getting_started.rst:1092 msgid "The shade framework can select and assign a free floating IP quickly" msgstr "" #: ../getting_started.rst:1098 msgid "" "When the instance boots, the `ex_userdata` variable value instructs the " "instance to deploy the Fractals application." msgstr "" #: ../getting_started.rst:1102 msgid "Associate a floating IP for external connectivity" msgstr "" #: ../getting_started.rst:1104 msgid "We'll cover networking in detail in :doc:`/networking`." msgstr "" #: ../getting_started.rst:1106 msgid "" "To see the application running, you must know where to look for it. By " "default, your instance has outbound network access. To make your instance " "reachable from the Internet, you need an IP address. By default in some " "cases, your instance is provisioned with a publicly rout-able IP address. In " "this case, you'll see an IP address listed under `public_ips` or " "`private_ips` when you list the instances. If not, you must create and " "attach a floating IP address to your instance." msgstr "" #: ../getting_started.rst:1121 msgid "This will get an ip address that you can assign to your instance with:" msgstr "" #: ../getting_started.rst:1131 msgid "" "Use :code:`ex_list_floating_ip_pools()` and select the first floating IP " "address pool. Allocate this pool to your project and attach it to your " "instance." msgstr "" #: ../getting_started.rst:1139 ../getting_started.rst:1162 msgid "This code returns the floating IP address:" msgstr "" #: ../getting_started.rst:1145 ../getting_started.rst:1168 msgid "You can then attach it to the instance:" msgstr "" #: ../getting_started.rst:1154 msgid "" "Use :code:`getFloatingIps` to check for unused addresses, selecting the " "first one if available, otherwise use :code:`allocateNewFloatingIp` to " "allocate a new Floating IP to your project from the default address pool." msgstr "" #: ../getting_started.rst:1181 msgid "Run the script to start the deployment." msgstr "" #: ../getting_started.rst:1184 msgid "Access the application" msgstr "" #: ../getting_started.rst:1186 msgid "" "Deploying application data and configuration to the instance can take some " "time. Consider enjoying a cup of coffee while you wait. After the " "application deploys, you can visit the awesome graphic interface at the " "following link by using your preferred browser." msgstr "" #: ../getting_started.rst:1212 msgid "" "If you do not use floating IPs, substitute another IP address as appropriate" msgstr "" #: ../getting_started.rst:1224 msgid "" "Don't worry if these concepts are not yet completely clear. In :doc:`/" "introduction`, we explore these concepts in more detail." msgstr "" #: ../getting_started.rst:1227 msgid ":doc:`/scaling_out`: Learn how to scale your application" msgstr "" #: ../getting_started.rst:1228 msgid "" ":doc:`/durability`: Learn how to use Object Storage to make your application " "durable" msgstr "" #: ../getting_started.rst:1229 ../introduction.rst:646 ../scaling_out.rst:425 msgid "" ":doc:`/block_storage`: Migrate the database to block storage, or use the " "database-as-a-service component" msgstr "" #: ../getting_started.rst:1231 ../scaling_out.rst:427 msgid ":doc:`/orchestration`: Automatically orchestrate your application" msgstr "" #: ../getting_started.rst:1232 ../scaling_out.rst:428 msgid ":doc:`/networking`: Learn about complex networking" msgstr "" #: ../getting_started.rst:1233 ../introduction.rst:650 ../scaling_out.rst:429 msgid ":doc:`/advice`: Get advice about operations" msgstr "" #: ../getting_started.rst:1234 ../introduction.rst:651 ../scaling_out.rst:430 msgid "" ":doc:`/craziness`: Learn some crazy things that you might not think to do ;)" msgstr "" #: ../getting_started.rst:1239 ../introduction.rst:655 ../scaling_out.rst:434 msgid "Complete code sample" msgstr "" #: ../getting_started.rst:1241 ../introduction.rst:657 ../scaling_out.rst:436 msgid "" "The following file contains all of the code from this section of the " "tutorial. This comprehensive code sample lets you view and run the code as a " "single script." msgstr "" #: ../getting_started.rst:1245 ../introduction.rst:660 ../scaling_out.rst:440 msgid "" "Before you run this script, confirm that you have set your authentication " "information, the flavor ID, and image ID." msgstr "" #: ../index.rst:3 msgid "Writing your first OpenStack application" msgstr "" #: ../index.rst:6 msgid "Contents" msgstr "" #: ../index.rst:26 msgid "Search in this guide" msgstr "" #: ../index.rst:28 msgid ":ref:`search`" msgstr "" #: ../introduction.rst:3 msgid "Introduction to the fractals application architecture" msgstr "" #: ../introduction.rst:5 msgid "" "This section introduces the application architecture and explains how it was " "designed to take advantage of cloud features in general and OpenStack in " "particular. It also describes some commands in the previous section." msgstr "" #: ../introduction.rst:38 msgid "Cloud application architecture principles" msgstr "" #: ../introduction.rst:40 msgid "" "Cloud applications typically share several design principles. These " "principles influenced the design of the Fractals application." msgstr "" #: ../introduction.rst:48 msgid "Modularity and micro-services" msgstr "" #: ../introduction.rst:50 msgid "" "`Micro-services `_ are an " "important design pattern that helps achieve application modularity. " "Separating logical application functions into independent services " "simplifies maintenance and re-use. Decoupling components also makes it " "easier to selectively scale individual components, as required. Further, " "application modularity is a required feature of applications that scale out " "well and are fault tolerant." msgstr "" #: ../introduction.rst:58 msgid "Scalability" msgstr "" #: ../introduction.rst:60 msgid "" "Cloud applications often use many small instances rather than a few large " "instances. Provided that an application is sufficiently modular, you can " "easily distribute micro-services across as many instances as required. This " "architecture enables an application to grow past the limit imposed by the " "maximum size of an instance. It's like trying to move a large number of " "people from one place to another; there's only so many people you can put on " "the largest bus, but you can use an unlimited number of buses or small cars, " "which provide just the capacity you need - and no more." msgstr "" #: ../introduction.rst:70 msgid "Fault tolerance" msgstr "" #: ../introduction.rst:72 msgid "" "In cloud programming, there's a well-known analogy known as \"cattle vs pets" "\". If you haven't heard it before, it goes like this:" msgstr "" #: ../introduction.rst:75 msgid "" "When you're dealing with pets, you name them and care for them and if they " "get sick, you nurse them back to health. Nursing pets back to health can be " "difficult and very time consuming. When you're dealing with cattle, you " "attach a numbered tag to their ear and if they get sick you put them down " "and move on." msgstr "" #: ../introduction.rst:81 msgid "" "That, as it happens, is the new reality of programming. Applications and " "systems used to be created on large, expensive servers, cared for by " "operations staff dedicated to keeping them healthy. If something went wrong " "with one of those servers, the staff's job was to do whatever it took to " "make it right again and save the server and the application." msgstr "" #: ../introduction.rst:88 msgid "" "In cloud programming, it's very different. Rather than large, expensive " "servers, you're dealing with virtual machines that are literally disposable; " "if something goes wrong, you shut it down and spin up a new one. There's " "still operations staff, but rather than nursing individual servers back to " "health, their job is to monitor the health of the overall system." msgstr "" #: ../introduction.rst:95 msgid "" "There are definite advantages to this architecture. It's easy to get a \"new" "\" server, without any of the issues that inevitably arise when a server has " "been up and running for months, or even years." msgstr "" #: ../introduction.rst:99 msgid "" "As with classical infrastructure, failures of the underpinning cloud " "infrastructure (hardware, networks, and software) are unavoidable. When " "you're designing for the cloud, it's crucial that your application is " "designed for an environment where failures can happen at any moment. This " "may sound like a liability, but it's not; by designing your application with " "a high degree of fault tolerance, you're also making it resilient in the " "face of change, and therefore more adaptable." msgstr "" #: ../introduction.rst:108 msgid "Fault tolerance is essential to the cloud-based application." msgstr "" #: ../introduction.rst:111 msgid "Automation" msgstr "" #: ../introduction.rst:113 msgid "" "If an application is meant to automatically scale up and down to meet " "demand, it is not feasible have any manual steps in the process of deploying " "any component of the application. Automation also decreases the time to " "recovery for your application in the event of component failures, increasing " "fault tolerance and resilience." msgstr "" #: ../introduction.rst:120 msgid "Programmatic interfaces (APIs)" msgstr "" #: ../introduction.rst:122 msgid "" "Like many cloud applications, the Fractals application has a `RESTful API " "`_. You can " "connect to it directly and generate fractals, or you can integrate it as a " "component of a larger application. Any time a standard interface such as an " "API is available, automated testing becomes much more feasible, increasing " "software quality." msgstr "" #: ../introduction.rst:130 msgid "Fractals application architecture" msgstr "" #: ../introduction.rst:132 msgid "" "The Fractals application was designed with the principles of the previous " "subsection in mind. You'll note that in :doc:`getting_started`, we deployed " "the application in an all-in-one style, on a single virtual machine. This " "isn't good practice, but because the application uses micro-services to " "decouple logical application functions, we can change this easily." msgstr "" #: ../introduction.rst:140 msgid "" "Message queues are used to facilitate communication between the Fractal " "application services. The Fractal application uses a `work queue `_ (or task queue) to " "distribute tasks to the worker services." msgstr "" #: ../introduction.rst:145 msgid "" "Message queues work in a way similar to a queue (or a line, for those of us " "on the other side of the ocean) in a bank being served by multiple clerks. " "The message queue in our application provides a feed of work requests that " "can be taken one-at-a-time by worker services, whether there is a single " "worker service or hundreds of them." msgstr "" #: ../introduction.rst:151 msgid "" "This is a `useful pattern `_ for many cloud applications that have long lists of requests coming " "in and a pool of resources from which to service them. This also means that " "a worker may crash and the tasks will be processed by other workers." msgstr "" #: ../introduction.rst:156 msgid "" "The `RabbitMQ getting started tutorial `_ provides a great introduction to message queues." msgstr "" #: ../introduction.rst:162 msgid "" "The worker service consumes messages from the work queue and then processes " "them to create the corresponding fractal image file." msgstr "" #: ../introduction.rst:165 msgid "" "Of course there's also a web interface which offers a more human friendly " "way of accessing the API to view the created fractal images, and a simple " "command line interface." msgstr "" #: ../introduction.rst:177 msgid "" "There are also multiple storage back ends (to store the generated fractal " "images) and a database component (to store the state of tasks), but we'll " "talk about those in :doc:`/durability` and :doc:`/block_storage` " "respectively." msgstr "" #: ../introduction.rst:183 msgid "How the Fractals application interacts with OpenStack" msgstr "" #: ../introduction.rst:196 msgid "The magic revisited" msgstr "" #: ../introduction.rst:198 msgid "" "So what exactly was that request doing at the end of the previous section? " "Let's look at it again. (Note that in this subsection, we're just explaining " "what you've already done in the previous section; you don't need to execute " "these commands again.)" msgstr "" #: ../introduction.rst:216 msgid "" "We explained image and flavor in :doc:`getting_started`, so in the following " "sections, we will explain the other parameters in detail, including :code:" "`ex_userdata` (cloud-init) and :code:`ex_keyname` (key pairs)." msgstr "" #: ../introduction.rst:222 msgid "Introduction to cloud-init" msgstr "" #: ../introduction.rst:224 msgid "" "`cloud-init `_ is a tool that " "performs instance configuration tasks during the boot of a cloud instance, " "and comes installed on most cloud images. :code:`ex_userdata`, which was " "passed to :code:`create_node`, is the configuration data passed to cloud-" "init." msgstr "" #: ../introduction.rst:230 msgid "" "In this case, we are presenting a shell script as the `userdata `_. " "When :code:`create_node` creates the instance, :code:`cloud-init` executes " "the shell script in the :code:`userdata` variable." msgstr "" #: ../introduction.rst:235 msgid "" "When an SSH public key is provided during instance creation, cloud-init " "installs this key on a user account. (The user name varies between cloud " "images.) See the `Obtaining Images `_ section of the image guide for guidance " "about which user name you should use when SSHing. If you still have problems " "logging in, ask your cloud provider to confirm the user name." msgstr "" #: ../introduction.rst:256 msgid "" "After the instance is created, cloud-init downloads and runs a script " "called :code:`install.sh`. This script installs the Fractals application. " "Cloud-init can consume bash scripts and a number of different types of data. " "You can even provide multiple types of data. You can find more information " "about cloud-init in the `official documentation `_." msgstr "" #: ../introduction.rst:263 msgid "Introduction to key pairs" msgstr "" #: ../introduction.rst:265 msgid "" "Security is important when it comes to your instances; you can't have just " "anyone accessing them. To enable logging into an instance, you must provide " "the public key of an SSH key pair during instance creation. In section one, " "you created and uploaded a key pair to OpenStack, and cloud-init installed " "it for the user account." msgstr "" #: ../introduction.rst:271 msgid "" "Even with a key in place, however, you must have the appropriate security " "group rules in place to access your instance." msgstr "" #: ../introduction.rst:275 msgid "Introduction to security groups" msgstr "" #: ../introduction.rst:277 msgid "" "Security groups are sets of network access rules that are applied to an " "instance's networking. By default, only egress (outbound) traffic is " "allowed. You must explicitly enable ingress (inbound) network access by " "creating a security group rule." msgstr "" #: ../introduction.rst:282 msgid "" "Removing the egress rule created by OpenStack will cause your instance " "networking to break." msgstr "" #: ../introduction.rst:285 msgid "" "Start by creating a security group for the all-in-one instance and adding " "the appropriate rules, such as HTTP (TCP port 80) and SSH (TCP port 22):" msgstr "" #: ../introduction.rst:302 msgid "" ":code:`ex_create_security_group_rule()` takes ranges of ports as input. This " "is why ports 80 and 22 are passed twice." msgstr "" #: ../introduction.rst:306 msgid "You can list available security groups with:" msgstr "" #: ../introduction.rst:322 msgid "Once you've created a rule or group, you can also delete it:" msgstr "" #: ../introduction.rst:338 msgid "To see which security groups apply to an instance, you can:" msgstr "" #: ../introduction.rst:356 msgid "" "Once you've configured permissions, you'll need to know where to access the " "application." msgstr "" #: ../introduction.rst:360 msgid "Introduction to Floating IPs" msgstr "" #: ../introduction.rst:362 msgid "" "As in traditional IT, cloud instances are accessed through IP addresses that " "OpenStack assigns. How this is actually done depends on the networking setup " "for your cloud. In some cases, you will simply get an Internet rout-able IP " "address assigned directly to your instance." msgstr "" #: ../introduction.rst:367 msgid "" "The most common way for OpenStack clouds to allocate Internet rout-able IP " "addresses to instances, however, is through the use of floating IPs. A " "floating IP is an address that exists as an entity unto itself, and can be " "associated to a specific instance network interface. When a floating IP " "address is associated to an instance network interface, OpenStack re-directs " "traffic bound for that address to the address of the instance's internal " "network interface address. Your cloud provider will generally offer pools of " "floating IPs for your use." msgstr "" #: ../introduction.rst:377 msgid "" "To use a floating IP, you must first allocate an IP to your project, then " "associate it to your instance's network interface." msgstr "" #: ../introduction.rst:382 msgid "" "Allocating a floating IP address to an instance does not change the IP " "address of the instance, it causes OpenStack to establish the network " "translation rules to allow an *additional* IP address." msgstr "" #: ../introduction.rst:393 msgid "" "If you have no free floating IPs that have been previously allocated for " "your project, first select a floating IP pool offered by your provider. In " "this example, we have selected the first one and assume that it has " "available IP addresses." msgstr "" #: ../introduction.rst:402 msgid "" "Now request that an address from this pool be allocated to your project." msgstr "" #: ../introduction.rst:415 msgid "" "Now that you have an unused floating IP address allocated to your project, " "attach it to an instance." msgstr "" #: ../introduction.rst:431 msgid "" "That brings us to where we ended up at the end of :doc:`/getting_started`. " "But where do we go from here?" msgstr "" #: ../introduction.rst:435 msgid "Splitting services across multiple instances" msgstr "" #: ../introduction.rst:437 msgid "" "We've talked about separating functions into different micro-services, and " "how that enables us to make use of the cloud architecture. Now let's see " "that in action." msgstr "" #: ../introduction.rst:441 msgid "" "The rest of this tutorial won't reference the all-in-one instance you " "created in section one. Take a moment to delete this instance." msgstr "" #: ../introduction.rst:444 msgid "" "It's easy to split out services into multiple instances. We will create a " "controller instance called :code:`app-controller`, which hosts the API, " "database, and messaging services. We'll also create a worker instance " "called :code:`app-worker-1`, which just generates fractals." msgstr "" #: ../introduction.rst:450 msgid "" "The first step is to start the controller instance. The instance has the API " "service, the database, and the messaging service, as you can see from the " "parameters passed to the installation script." msgstr "" #: ../introduction.rst:455 ../introduction.rst:508 msgid "Parameter" msgstr "" #: ../introduction.rst:455 msgid "Values" msgstr "" #: ../introduction.rst:457 msgid ":code:`-i`" msgstr "" #: ../introduction.rst:457 msgid "" ":code:`messaging` (install RabbitMQ) and :code:`faafo` (install the Faafo " "app)." msgstr "" #: ../introduction.rst:457 msgid "Install a service" msgstr "" #: ../introduction.rst:458 msgid ":code:`-r`" msgstr "" #: ../introduction.rst:458 msgid "" ":code:`api` (enable and start the API service), :code:`worker` (enable and " "start the worker service), and :code:`demo` (run the demo mode to request " "random fractals)." msgstr "" #: ../introduction.rst:458 msgid "Enable/start something" msgstr "" #: ../introduction.rst:477 msgid "" "Note that this time, when you create a security group, you're including a " "rule that only applies for instances that are part of the worker_group." msgstr "" #: ../introduction.rst:481 msgid "Next, start a second instance, which will be the worker instance:" msgstr "" #: ../introduction.rst:498 msgid "" "Notice that you've added this instance to the worker_group, so it can access " "the controller." msgstr "" #: ../introduction.rst:501 msgid "" "As you can see from the parameters passed to the installation script, you " "are specifying that this is the worker instance, but you're also passing the " "address of the API instance and the message queue so the worker can pick up " "requests. The Fractals application installation script can take several " "parameters." msgstr "" #: ../introduction.rst:508 msgid "Example" msgstr "" #: ../introduction.rst:510 msgid ":code:`-e`" msgstr "" #: ../introduction.rst:510 msgid "The endpoint URL of the API service." msgstr "" #: ../introduction.rst:510 msgid "http://localhost/" msgstr "" #: ../introduction.rst:511 msgid ":code:`-m`" msgstr "" #: ../introduction.rst:511 msgid "The transport URL of the messaging service." msgstr "" #: ../introduction.rst:511 msgid "amqp://guest:guest@localhost:5672/" msgstr "" #: ../introduction.rst:512 msgid ":code:`-d`" msgstr "" #: ../introduction.rst:512 msgid "The connection URL for the database (not used here)." msgstr "" #: ../introduction.rst:512 msgid "sqlite:////tmp/sqlite.db" msgstr "" #: ../introduction.rst:515 msgid "" "Now if you make a request for a new fractal, you connect to the controller " "instance, :code:`app-controller`, but the work will actually be performed by " "a separate worker instance - :code:`app-worker-1`." msgstr "" #: ../introduction.rst:521 msgid "Login with SSH and use the Fractal app" msgstr "" #: ../introduction.rst:523 msgid "" "Login to the worker instance, :code:`app-worker-1`, with SSH, using the " "previous added SSH key pair \"demokey\". Start by getting the IP address of " "the worker:" msgstr "" #: ../introduction.rst:540 msgid "Now you can SSH into the instance:" msgstr "" #: ../introduction.rst:546 msgid "" "Replace :code:`IP_WORKER_1` with the IP address of the worker instance and " "USERNAME to the appropriate user name." msgstr "" #: ../introduction.rst:549 msgid "" "Once you've logged in, check to see whether the worker service process is " "running as expected. You can find the logs of the worker service in the " "directory :code:`/var/log/supervisor/`." msgstr "" #: ../introduction.rst:558 msgid "" "Open :code:`top` to monitor the CPU usage of the :code:`faafo-worker` " "process." msgstr "" #: ../introduction.rst:560 msgid "" "Now log into the controller instance, :code:`app-controller`, also with SSH, " "using the previously added SSH key pair \"demokey\"." msgstr "" #: ../introduction.rst:567 msgid "" "Replace :code:`IP_CONTROLLER` with the IP address of the controller instance " "and USERNAME to the appropriate user name." msgstr "" #: ../introduction.rst:570 msgid "" "Check to see whether the API service process is running like expected. You " "can find the logs for the API service in the directory :file:`/var/log/" "supervisor/`." msgstr "" #: ../introduction.rst:579 msgid "" "Now call the Fractal application's command line interface (:code:`faafo`) to " "request a few new fractals. The following command requests a few fractals " "with random parameters:" msgstr "" #: ../introduction.rst:588 msgid "" "Watch :code:`top` on the worker instance. Right after calling :code:`faafo` " "the :code:`faafo-worker` process should start consuming a lot of CPU cycles." msgstr "" #: ../introduction.rst:597 msgid "" "To show the details of a specific fractal use the subcommand :code:`show` of " "the Faafo CLI." msgstr "" #: ../introduction.rst:618 msgid "" "There are more commands available; find out more details about them with :" "code:`faafo get --help`, :code:`faafo list --help`, and :code:`faafo delete " "--help`." msgstr "" #: ../introduction.rst:622 msgid "" "The application stores the generated fractal images directly in the database " "used by the API service instance. Storing image files in a database is not " "good practice. We're doing it here as an example only as an easy way to " "allow multiple instances to have access to the data. For best practice, we " "recommend storing objects in Object Storage, which is covered in :doc:" "`durability`." msgstr "" #: ../introduction.rst:633 msgid "" "You should now have a basic understanding of the architecture of cloud-based " "applications. In addition, you have had practice starting new instances, " "automatically configuring them at boot, and even modularizing an application " "so that you may use multiple instances to run it. These are the basic steps " "for requesting and using compute resources in order to run your application " "on an OpenStack cloud." msgstr "" #: ../introduction.rst:641 msgid "" "From here, you should go to :doc:`/scaling_out` to learn how to scale your " "application further. Alternatively, you may jump to any of these sections:" msgstr "" #: ../introduction.rst:645 msgid "" ":doc:`/durability`: Learn how to use Object Storage to make your application " "more durable" msgstr "" #: ../introduction.rst:648 msgid ":doc:`/orchestration`: Automatically orchestrate the application" msgstr "" #: ../introduction.rst:649 msgid ":doc:`/networking`: Learn about more complex networking" msgstr "" #: ../networking.rst:3 msgid "Networking" msgstr "" #: ../networking.rst:8 msgid "" "Prior to this chapter, all of the nodes that comprise the fractal " "application were attached to the same network." msgstr "" #: ../networking.rst:11 msgid "" "In this section of the tutorial, we introduce the Networking API. This will " "enable us to build networking topologies that separate public traffic " "accessing the application from traffic between the API and the worker " "components. We also introduce load balancing for resilience, and create a " "secure back-end network for communication between the database, webserver, " "file storage, and worker components." msgstr "" #: ../networking.rst:18 msgid "" "This section assumes your cloud provider has implemented the OpenStack " "Networking API (neutron). Users of clouds which have implemented legacy " "networking (nova-network) will have access to networking via the Compute " "API. Log in to the Horizon dashboard and navigate to :guilabel:`Project-" ">Access & Security->API Access`. If you see a service endpoint for the " "Network API, your cloud is most likely running the Networking API. If you " "are still in doubt, ask your cloud provider for more information." msgstr "" #: ../networking.rst:29 msgid "This section has not yet been completed for the .NET SDK" msgstr "" #: ../networking.rst:33 msgid "" "fog `supports `_ the OpenStack Networking API, but this section has not yet been " "completed." msgstr "" #: ../networking.rst:47 msgid "Libcloud does not support the OpenStack Networking API." msgstr "" #: ../networking.rst:51 msgid "" "Pkgcloud supports the OpenStack Networking API, but this section has not " "been completed." msgstr "" #: ../networking.rst:64 msgid "Working with the CLI" msgstr "" #: ../networking.rst:66 msgid "" "As SDKs don't currently fully support the OpenStack Networking API, this " "section uses the command-line clients." msgstr "" #: ../networking.rst:69 msgid "" "Install the 'neutron' command-line client by following this guide: http://" "docs.openstack.org/cli-reference/content/install_clients.html" msgstr "" #: ../networking.rst:72 msgid "" "Then set up the necessary variables for your cloud in an 'openrc' file using " "this guide: http://docs.openstack.org/cli-reference/content/cli_openrc.html" msgstr "" #: ../networking.rst:76 msgid "" "Ensure you have an openrc.sh file, source it and then check your neutron " "client works: ::" msgstr "" #: ../networking.rst:92 msgid "Networking segmentation" msgstr "" #: ../networking.rst:94 msgid "" "In traditional datacenters, network segments are dedicated to specific types " "of network traffic." msgstr "" #: ../networking.rst:97 msgid "" "The fractal application we are building contains three types of network " "traffic:" msgstr "" #: ../networking.rst:100 msgid "public-facing web traffic" msgstr "" #: ../networking.rst:101 msgid "API traffic" msgstr "" #: ../networking.rst:102 msgid "internal worker traffic" msgstr "" #: ../networking.rst:104 msgid "" "For performance reasons, it makes sense to have a network for each tier, so " "that traffic from one tier does not \"crowd out\" other types of traffic and " "cause the application to fail. In addition, having separate networks makes " "controlling access to parts of the application easier to manage, improving " "the overall security of the application." msgstr "" #: ../networking.rst:110 msgid "" "Prior to this section, the network layout for the Fractal application would " "be similar to the following diagram:" msgstr "" #: ../networking.rst:133 msgid "" "In this network layout, we are assuming that the OpenStack cloud in which " "you have been building your application has a public network and tenant " "router that was previously created by your cloud provider or by yourself, " "following the instructions in the appendix." msgstr "" #: ../networking.rst:138 msgid "" "Many of the network concepts that are discussed in this section are already " "present in the diagram above. A tenant router provides routing and external " "access for the worker nodes, and floating IP addresses are associated with " "each node in the Fractal application cluster to facilitate external access." msgstr "" #: ../networking.rst:144 msgid "" "At the end of this section, we will be making some slight changes to the " "networking topology by using the OpenStack Networking API to create a " "network to which the worker nodes will attach (10.0.1.0/24). We will use the " "API network (10.0.3.0/24) to attach the Fractal API servers. Webserver " "instances have their own network (10.0.2.0/24) and will be accessible by " "fractal aficionados worldwide, by allocating floating IPs from the public " "network." msgstr "" #: ../networking.rst:183 msgid "Introduction to tenant networking" msgstr "" #: ../networking.rst:185 msgid "" "With the OpenStack Networking API, the workflow for creating a network " "topology that separates the public-facing Fractals app API from the worker " "back end is as follows:" msgstr "" #: ../networking.rst:189 msgid "Create a network and subnet for the web server nodes." msgstr "" #: ../networking.rst:191 msgid "" "Create a network and subnet for the worker nodes. This is the private data " "network." msgstr "" #: ../networking.rst:193 msgid "Create a router for the private data network." msgstr "" #: ../networking.rst:195 msgid "Allocate floating ips and assign them to the web server nodes." msgstr "" #: ../networking.rst:198 msgid "Creating networks" msgstr "" #: ../networking.rst:200 msgid "" "Most cloud providers will make a public network accessible to you. We will " "attach a router to this public network to grant Internet access to our " "instances. After also attaching this router to our internal networks, we " "will allocate floating IPs from the public network for instances which need " "to be accessed from the Internet." msgstr "" #: ../networking.rst:206 msgid "" "Let's just confirm that we have a public network by listing the networks our " "tenant has access to. The public network doesn't have to be named public - " "it could be 'external', 'net04_ext' or something else - the important thing " "is it exists and can be used to reach the internet." msgstr "" #: ../networking.rst:220 msgid "Next, create a network and subnet for the workers." msgstr "" #: ../networking.rst:259 msgid "Now, create a network and subnet for the webservers." msgstr "" #: ../networking.rst:299 msgid "Next, create a network and subnet for the API servers." msgstr "" #: ../networking.rst:339 msgid "" "Now that you've got the networks created, go ahead and create two Floating " "IPs, for web servers. Ensure that you replace 'public' with the name of the " "public/external network offered by your cloud provider." msgstr "" #: ../networking.rst:375 msgid "" "The world is running out of IPv4 addresses. If you get an error like \"No " "more IP addresses available on network\", contact your cloud administrator. " "You may also want to ask about IPv6 :)" msgstr "" #: ../networking.rst:381 msgid "Connecting to the Internet" msgstr "" #: ../networking.rst:383 msgid "" "Most instances will need access to the Internet. The instances in our " "Fractals App are no exception! We'll add routers to pass traffic between the " "various networks we are using." msgstr "" #: ../networking.rst:403 msgid "" "We tell OpenStack which network should be used for Internet access by " "specifying an external gateway for our router." msgstr "" #: ../networking.rst:426 msgid "Now, attach our router to the worker, api, and webserver subnets." msgstr "" #: ../networking.rst:440 msgid "Booting a worker" msgstr "" #: ../networking.rst:442 msgid "" "Now that you've prepared the networking infrastructure, you can go ahead and " "boot an instance on it. Ensure you use appropriate flavor and image values " "for your cloud - see :doc:`getting_started` if you've not already." msgstr "" #: ../networking.rst:485 msgid "Load balancing" msgstr "" #: ../networking.rst:487 msgid "" "After separating the Fractal worker nodes into their own network, the next " "logical step is to move the Fractal API service onto a load balancer, so " "that multiple API workers can handle requests. By using a load balancer, the " "API service can be scaled out in a similar fashion to the worker nodes." msgstr "" #: ../networking.rst:494 msgid "Neutron LbaaS API" msgstr "" #: ../networking.rst:496 msgid "" "This section is based on the Neutron LBaaS API version 1.0 http://docs." "openstack.org/admin-guide-cloud/networking_adv-features.html#basic-load-" "balancer-as-a-service-operations" msgstr "" #: ../networking.rst:503 msgid "" "The OpenStack Networking API provides support for creating loadbalancers, " "which can be used to scale the Fractal app web service. In the following " "example, we create two compute instances via the Compute API, then " "instantiate a load balancer that will use a virtual IP (VIP) for accessing " "the web service offered by the two compute nodes. The end result will be the " "following network topology:" msgstr "" #: ../networking.rst:528 msgid "" "libcloud support added 0.14: https://developer.rackspace.com/blog/libcloud-0-" "dot-14-released/" msgstr "" #: ../networking.rst:531 msgid "Let's start by looking at what's already in place." msgstr "" #: ../networking.rst:543 msgid "Now let's go ahead and create 2 instances." msgstr "" #: ../networking.rst:579 msgid "Confirm that they were added:" msgstr "" #: ../networking.rst:591 msgid "Now let's look at what ports are available:" msgstr "" #: ../networking.rst:605 msgid "" "Next create additional floating IPs by specifying the fixed IP addresses " "they should point to and the ports they should use:" msgstr "" #: ../networking.rst:639 msgid "" "All right, now you're ready to go ahead and create members for the load " "balancer pool, referencing the floating IPs:" msgstr "" #: ../networking.rst:676 msgid "You should be able to see them in the member list:" msgstr "" #: ../networking.rst:688 msgid "" "Now let's create a health monitor that will ensure that members of the load " "balancer pool are active and able to respond to requests. If a member in the " "pool dies or is unresponsive, the member is removed from the pool so that " "client requests are routed to another active member." msgstr "" #: ../networking.rst:715 msgid "" "Now create a virtual IP that will be used to direct traffic between the " "various members of the pool:" msgstr "" #: ../networking.rst:742 msgid "And confirm it's in place:" msgstr "" #: ../networking.rst:753 msgid "Now let's look at the big picture." msgstr "" #: ../networking.rst:756 msgid "Final result" msgstr "" #: ../networking.rst:758 msgid "" "With the addition of the load balancer, the Fractal app's networking " "topology now reflects the modular nature of the application itself." msgstr "" #: ../networking.rst:797 msgid "" "You should now be fairly confident working with the Network API. There are " "several calls we did not cover. To see these and more, refer to the volume " "documentation of your SDK, or try a different step in the tutorial, " "including:" msgstr "" #: ../networking.rst:803 msgid "" ":doc:`/craziness`: to see all the crazy things we think ordinary folks won't " "want to do ;)" msgstr "" #: ../orchestration.rst:3 msgid "Orchestration" msgstr "" #: ../orchestration.rst:7 msgid "" "Sorry! We're not quite happy with this chapter. It will give you an " "introduction to heat, but it's a little dry at the moment. We'd like to " "write a template for the Fractals app instead of using the \"hello world\" " "style ones, so stay tuned!" msgstr "" #: ../orchestration.rst:11 msgid "" "Throughout this guide, we've talked about the importance of durability and " "scalability for your cloud-based applications. In most cases, really " "achieving these qualities means automating tasks such as scaling and other " "operational tasks." msgstr "" #: ../orchestration.rst:15 msgid "" "The Orchestration module provides a template-based way to describe a cloud " "application, then coordinates running the needed OpenStack API calls to run " "cloud applications. The templates allow you to create most OpenStack " "resource types, such as instances, networking information, volumes, security " "groups and even users. It also provides more advanced functionality, such as " "instance high availability, instance auto-scaling, and nested stacks." msgstr "" #: ../orchestration.rst:22 msgid "The OpenStack Orchestration API contains the following constructs:" msgstr "" #: ../orchestration.rst:24 msgid "Stacks" msgstr "" #: ../orchestration.rst:25 msgid "Resources" msgstr "" #: ../orchestration.rst:26 msgid "Templates" msgstr "" #: ../orchestration.rst:28 msgid "" "Stacks are created from Templates, which contain Resources. Resources are an " "abstraction in the HOT (Heat Orchestration Template) template language, " "which enables you to define different cloud resources by setting the `type` " "attribute." msgstr "" #: ../orchestration.rst:32 msgid "" "For example, you might use the Orchestration API to create two compute " "instances by creating a Stack and by passing a Template to the Orchestration " "API. That Template would contain two Resources with the `type` attribute set " "to `OS::Nova::Server`." msgstr "" #: ../orchestration.rst:36 msgid "" "That's a simplistic example, of course, but the flexibility of the Resource " "object enables the creation of Templates that contain all the required cloud " "infrastructure to run an application, such as load balancers, block storage " "volumes, compute instances, networking topology, and security policies." msgstr "" #: ../orchestration.rst:41 msgid "" "The Orchestration module isn't deployed by default in every cloud. If these " "commands don't work, it means the Orchestration API isn't available; ask " "your support team for assistance." msgstr "" #: ../orchestration.rst:43 msgid "" "This section introduces the `HOT templating language `_, and takes you through " "some of the common calls you will make when working with OpenStack " "Orchestration." msgstr "" #: ../orchestration.rst:46 msgid "" "Unlike previous sections of this guide, in which you used your SDK to " "programmatically interact with OpenStack, in this section you'll be using " "the Orchestration API directly through Template files, so we'll work from " "the command line." msgstr "" #: ../orchestration.rst:50 msgid "" "Install the 'heat' commandline client by following this guide: http://docs." "openstack.org/cli-reference/content/install_clients.html" msgstr "" #: ../orchestration.rst:53 msgid "" "then set up the necessary variables for your cloud in an 'openrc' file using " "this guide: http://docs.openstack.org/cli-reference/content/cli_openrc.html" msgstr "" #: ../orchestration.rst:58 msgid "the .NET SDK does not currently support OpenStack Orchestration" msgstr "" #: ../orchestration.rst:62 msgid "" "fog `does support OpenStack Orchestration `_." msgstr "" #: ../orchestration.rst:70 msgid "libcloud does not currently support OpenStack Orchestration." msgstr "" #: ../orchestration.rst:74 msgid "" "Pkgcloud supports OpenStack Orchestration :D:D:D but this section is `not " "written yet `_" msgstr "" #: ../orchestration.rst:85 msgid "HOT Templating Language" msgstr "" #: ../orchestration.rst:87 msgid "" "The best place to learn about the template syntax for OpenStack " "Orchestration is the `Heat Orchestration Template (HOT) Guide `_ You should " "read the HOT Guide first to learn how to create basic templates, their " "inputs and outputs." msgstr "" #: ../orchestration.rst:92 msgid "Working with Stacks: Basics" msgstr "" #: ../orchestration.rst:102 msgid "Stack create" msgstr "" #: ../orchestration.rst:104 msgid "" "In the following example, we use the `hello_world `_ Hot template to " "demonstrate creating a Nova compute instance, with a few configuration " "settings passed in, such as an administrative password and the unique " "identifier (UUID) of an image:" msgstr "" #: ../orchestration.rst:119 msgid "" "The resulting stack creates a Nova instance automatically, which you can see " "here:" msgstr "" #: ../orchestration.rst:130 msgid "" "Verify that the stack was successfully created using the following command:" msgstr "" #: ../orchestration.rst:141 msgid "Remove the stack:" msgstr "" #: ../orchestration.rst:152 msgid "Verify that the removal of the stack has deleted the nova instance:" msgstr "" #: ../orchestration.rst:162 msgid "" "While this stack is not very interesting - it just starts a single instance " "- it is possible to make very complicated templates that involve dozens of " "instances or adds and removes instances based on demand. Continue to the " "next section to learn more." msgstr "" #: ../orchestration.rst:168 msgid "Working with Stacks: Advanced" msgstr "" #: ../orchestration.rst:174 msgid "" "With the use of the Orchestration API, the Fractal app can create an " "autoscaling group for all parts of the application, in order to dynamically " "provision more compute resources during periods of heavy utilization, and " "also terminate compute instances to scale down, as demand decreases." msgstr "" #: ../orchestration.rst:179 msgid "" "There are two helpful articles available to learn about autoscaling with the " "Orchestration API:" msgstr "" #: ../orchestration.rst:182 msgid "" "http://superuser.openstack.org/articles/simple-auto-scaling-environment-with-" "heat" msgstr "" #: ../orchestration.rst:183 msgid "" "http://superuser.openstack.org/articles/understanding-openstack-heat-auto-" "scaling" msgstr "" #: ../orchestration.rst:185 msgid "" "An example template that creates an auto-scaling wordpress instance can be " "found in `the heat template repository `_" msgstr "" #: ../orchestration.rst:190 msgid "Next Steps" msgstr "" #: ../orchestration.rst:192 msgid "" "You should now be fairly confident working with the Orchestration service. " "There are several calls we did not cover. To see these and more, refer to " "the volume documentation of your SDK, or try a different step in the " "tutorial, including:" msgstr "" #: ../orchestration.rst:196 msgid ":doc:`/networking` - to learn about more complex networking" msgstr "" #: ../orchestration.rst:197 msgid ":doc:`/advice` - for advice for developers new to operations" msgstr "" #: ../orchestration.rst:198 msgid "" ":doc:`/craziness` - to see all the crazy things we think ordinary folks " "won't want to do ;)" msgstr "" #: ../scaling_out.rst:3 ../scaling_out.rst:149 msgid "Scaling out" msgstr "" #: ../scaling_out.rst:11 msgid "" "One of the most-often cited reasons for designing applications using cloud " "patterns is the ability to **scale out**. That is: to add additional " "resources as required. This is in contrast to the previous strategy of " "increasing capacity by scaling up the size of existing resources. In order " "for scale out to be feasible, you'll need to do two things:" msgstr "" #: ../scaling_out.rst:18 msgid "Architect your application to make use of additional resources." msgstr "" #: ../scaling_out.rst:19 msgid "Make it possible to add new resources to your application." msgstr "" #: ../scaling_out.rst:23 msgid "" "In section :doc:`/introduction`, we talked about various aspects of the " "application architecture, such as building in a modular fashion, creating an " "API, and so on. Now you'll see why those are so important. By creating a " "modular application with decoupled services, it is possible to identify " "components that cause application performance bottlenecks and scale them out." msgstr "" #: ../scaling_out.rst:30 msgid "" "Just as importantly, you can also remove resources when they are no longer " "necessary. It is very difficult to overstate the cost savings that this " "feature can bring, as compared to traditional infrastructure." msgstr "" #: ../scaling_out.rst:35 msgid "" "Of course, just having access to additional resources is only part of the " "battle; while it's certainly possible to manually add or destroy resources, " "you'll get more value -- and more responsiveness -- if the application " "simply requests new resources automatically when it needs them." msgstr "" #: ../scaling_out.rst:41 msgid "" "This section continues to illustrate the separation of services onto " "multiple instances and highlights some of the choices we've made that " "facilitate scalability in the app's architecture." msgstr "" #: ../scaling_out.rst:45 msgid "" "We'll progressively ramp up to use up to about six instances, so ensure that " "your cloud account has appropriate quota to handle that many." msgstr "" #: ../scaling_out.rst:48 msgid "" "In the previous section, we used two virtual machines - one 'control' " "service and one 'worker'. In our application, the speed at which fractals " "can be generated depends on the number of workers. With just one worker, we " "can only produce one fractal at a time. Before long, it will be clear that " "we need more resources." msgstr "" #: ../scaling_out.rst:54 msgid "" "If you don't have a working application, follow the steps in :doc:" "`introduction` to create one." msgstr "" #: ../scaling_out.rst:61 msgid "Generate load" msgstr "" #: ../scaling_out.rst:63 msgid "" "You can test for yourself what happens when the Fractals application is " "under load by:" msgstr "" #: ../scaling_out.rst:66 msgid "" "maxing out the CPU of the existing worker instances (loading the worker)" msgstr "" #: ../scaling_out.rst:67 msgid "generating a lot of API requests (load up the API)" msgstr "" #: ../scaling_out.rst:71 msgid "Create a greater number of tasks" msgstr "" #: ../scaling_out.rst:73 ../scaling_out.rst:110 msgid "" "Use SSH to login to the controller instance, :code:`app-controller`, using " "the previous added SSH keypair." msgstr "" #: ../scaling_out.rst:80 ../scaling_out.rst:117 msgid "" "Replace :code:`IP_CONTROLLER` with the IP address of the controller instance " "and USERNAME to the appropriate username." msgstr "" #: ../scaling_out.rst:84 msgid "" "Call the Fractal application's command line interface (:code:`faafo`) to " "request the generation of 5 large fractals." msgstr "" #: ../scaling_out.rst:91 msgid "" "Now if you check the load on the worker, you can see that the instance is " "not doing well. On our single CPU flavor instance, a load average of more " "than 1 means we are at capacity." msgstr "" #: ../scaling_out.rst:100 msgid "" "Replace :code:`IP_WORKER` with the IP address of the worker instance and " "USERNAME to the appropriate username." msgstr "" #: ../scaling_out.rst:105 msgid "Create a greater number of API service requests" msgstr "" #: ../scaling_out.rst:107 msgid "" "API load is a slightly different problem to the previous one regarding " "capacity to work. We can simulate many requests to the API as follows:" msgstr "" #: ../scaling_out.rst:121 msgid "" "Call the Fractal application's command line interface (:code:`faafo`) in a " "for loop to send many requests to the API. The following command will " "request a random set of fractals, 500 times:" msgstr "" #: ../scaling_out.rst:129 msgid "" "Replace :code:`IP_CONTROLLER` with the IP address of the controller instance." msgstr "" #: ../scaling_out.rst:132 msgid "" "Now if you check the load on the API service instance, :code:`app-" "controller`, you can see that the instance is not doing well. On our single " "CPU flavor instance, a load average of more than 1 means we are at capacity." msgstr "" #: ../scaling_out.rst:142 msgid "" "The number of requests coming in means that some requests for fractals may " "not even get onto the message queue to be processed. To ensure we can cope " "with demand, we need to scale out our API services as well." msgstr "" #: ../scaling_out.rst:146 msgid "" "As you can see, we need to scale out the Fractals application's API " "capability." msgstr "" #: ../scaling_out.rst:152 msgid "Remove the old app" msgstr "" #: ../scaling_out.rst:154 msgid "" "Go ahead and delete the existing instances and security groups you created " "in previous sections. Remember, when instances in the cloud are no longer " "working, remove them and re-create something new." msgstr "" #: ../scaling_out.rst:173 msgid "Extra security groups" msgstr "" #: ../scaling_out.rst:175 msgid "" "As you change the topology of your applications, you will need to update or " "create new security groups. Here, we will re-create the required security " "groups." msgstr "" #: ../scaling_out.rst:193 msgid "A Floating IP helper function" msgstr "" #: ../scaling_out.rst:195 msgid "" "Define a short function to locate unused IPs or allocate a new floating IP. " "This saves a few lines of code and prevents you from reaching your Floating " "IP quota too quickly." msgstr "" #: ../scaling_out.rst:213 msgid "Splitting off the database and message queue" msgstr "" #: ../scaling_out.rst:215 msgid "" "Prior to scaling out our application services, like the API service or the " "workers, we have to add a central database and messaging instance, called :" "code:`app-services`. The database and messaging queue will be used to track " "the state of the fractals and to coordinate the communication between the " "services." msgstr "" #: ../scaling_out.rst:235 msgid "Scaling the API service" msgstr "" #: ../scaling_out.rst:237 msgid "" "With multiple workers producing fractals as fast as they can, we also need " "to make sure we can receive the requests for fractals as quickly as " "possible. If our application becomes popular, we may have many thousands of " "users trying to connect to our API to generate fractals." msgstr "" #: ../scaling_out.rst:242 msgid "" "Armed with our security group, image and flavor size we can now add multiple " "API services:" msgstr "" #: ../scaling_out.rst:258 msgid "" "These are client-facing services, so unlike the workers they do not use a " "message queue to distribute tasks. Instead, we'll need to introduce some " "kind of load balancing mechanism to share incoming requests between the " "different API services." msgstr "" #: ../scaling_out.rst:263 msgid "" "One simple way might be to give half of our friends one address and half the " "other, but that's certainly not a sustainable solution. Instead, we can do " "that automatically using a `DNS round robin `_. However, OpenStack networking can provide Load Balancing " "as a Service, which we'll explain in :doc:`/networking`." msgstr "" #: ../scaling_out.rst:276 msgid "Scaling the workers" msgstr "" #: ../scaling_out.rst:278 msgid "To increase the overall capacity, we will now add 3 workers:" msgstr "" #: ../scaling_out.rst:294 msgid "" "Adding this capacity enables you to deal with a higher number of requests " "for fractals. As soon as these worker instances come up, they'll start " "checking the message queue looking for requests, reducing the overall " "backlog like a new register opening in the supermarket." msgstr "" #: ../scaling_out.rst:300 msgid "" "This was obviously a very manual process - figuring out we needed more " "workers and then starting new ones required some effort. Ideally the system " "would do this itself. If your application has been built to detect these " "situations, you can have it automatically request and remove resources, but " "you don't actually need to do this work yourself. Instead, the OpenStack " "Orchestration service can monitor load and start instances as appropriate. " "See :doc:`orchestration` to find out how to set that up." msgstr "" #: ../scaling_out.rst:310 msgid "Verifying we've had an impact" msgstr "" #: ../scaling_out.rst:312 msgid "" "In the steps above, we've split out several services and expanded capacity. " "SSH to one of the app instances and create a few fractals. You will see that " "the Fractals app has a few new features." msgstr "" #: ../scaling_out.rst:320 msgid "" "Replace :code:`IP_API_1` with the IP address of the first API instance and " "USERNAME to the appropriate username." msgstr "" #: ../scaling_out.rst:323 msgid "" "Use the Fractal application's command line interface to generate fractals :" "code:`faafo create`. Watch the progress of fractal generation with the :code:" "`faafo list`. Use :code:`faafo UUID` to examine some of the fractals. The " "generated_by field will show which worker created the fractal. The fact that " "multiple worker instances are sharing the work means that fractals will be " "generated more quickly and the death of a worker probably won't even be " "noticed." msgstr "" #: ../scaling_out.rst:376 msgid "" "The fractals are now available from any of the app-api hosts. Visit http://" "IP_API_1/fractal/FRACTAL_UUID and http://IP_API_2/fractal/FRACTAL_UUID to " "verify. Now you have multiple redundant web services. If one dies, the " "others can be used." msgstr "" #: ../scaling_out.rst:381 msgid "" "Replace :code:`IP_API_1` and :code:`IP_API_2` with the corresponding " "Floating IPs. Replace FRACTAL_UUID the UUID of an existing fractal." msgstr "" #: ../scaling_out.rst:385 msgid "" "Go ahead and test the fault tolerance. Start destroying workers and API " "instances. As long as you have one of each, your application should be fine. " "There is one weak point though. The database contains the fractals and " "fractal metadata. If you lose that instance, the application will stop. " "Future sections will work to address this weak point." msgstr "" #: ../scaling_out.rst:392 msgid "" "If we had a load balancer, we could distribute this load between the two " "different API services. As mentioned previously, there are several options. " "We will show one in :doc:`networking`." msgstr "" #: ../scaling_out.rst:396 msgid "" "You could in theory use a simple script to monitor the load on your workers " "and API services and trigger the creation of new instances, which you " "already know how to do. If you can see how to do that - congratulations, " "you're ready to create scalable cloud applications." msgstr "" #: ../scaling_out.rst:401 msgid "" "Of course, creating a monitoring system just for one application may not " "always be the best way. We recommend you look at :doc:`orchestration` to " "find out about how you can use OpenStack Orchestration's monitoring and " "autoscaling capabilities to do steps like this automatically." msgstr "" #: ../scaling_out.rst:410 msgid "" "You should be fairly confident now about starting new instances, and " "distributing services from an application amongst the instances." msgstr "" #: ../scaling_out.rst:413 msgid "" "As mentioned in :doc:`/introduction` the generated fractal images will be " "saved on the local filesystem of the API service instances. Because we now " "have multiple API instances up and running, the fractal images will be " "spread across multiple API services. This results in a number of :code:" "`IOError: [Errno 2] No such file or directory` exceptions when trying to " "download a fractal image from an API service instance not holding the " "fractal image on its local filesystem." msgstr "" #: ../scaling_out.rst:421 msgid "" "From here, you should go to :doc:`/durability` to learn how to use Object " "Storage to solve this problem in a elegant way. Alternatively, you may jump " "to any of these sections:" msgstr ""