forked from aws-samples/aws-codepipeline-s3-codedeploy-linux
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
110 lines (105 loc) · 12.4 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Sample Deployment</title>
<style>
body {
color: #ffffff;
background-color: #007f3f;
font-family: Arial, sans-serif;
font-size: 14px;
}
h1 {
font-size: 500%;
font-weight: normal;
margin-bottom: 0;
}
h2 {
font-size: 200%;
font-weight: normal;
margin-bottom: 0;
}
</style>
</head>
<body>
<div align="center">
<h1>Congratulations!</h1>
<h2>You have successfully created a pipeline that retrieved this source application from GitHub and
deployed it to one Amazon EC2 instance using AWS Elastic Beanstalk.
You’re one step closer to practicing continuous deployment! </h2>
<h3> Note: You might want to clear the cache to display the update correctly </h3>
<h4> AWS App Mesh is a service mesh based on the Envoy proxy that makes it easy to monitor and control microservices. App Mesh standardizes how your microservices communicate, giving you end-to-end visibility and helping to ensure high availability for your applications.
App Mesh gives you consistent visibility and network traffic controls for every microservice in an application. For more information, see the App Mesh User Guide.
This topic helps you to use AWS App Mesh with an existing microservice application running on Amazon EKS or Kubernetes on Amazon EC2. You can either integrate Kubernetes with App Mesh resources by completing the steps in this topic, or by installing the App Mesh Kubernetes integration components. The integration components automatically complete the tasks in this topic for you, enabling you to integrate with App Mesh directly from Kubernetes. For more information, see Configure App Mesh Integration with Kubernetes. </h4>
<h4>This tutorial guides you through deploying the Kubernetes dashboard to your Amazon EKS cluster, complete with CPU and memory metrics. It also helps you to create an Amazon EKS administrator service account that you can use to securely connect to the dashboard to view and control your cluster.
Important
Kubernetes versions 1.11 and above do not support heapster memory and CPU metrics in the dashboard by default. The community is working to replace heapster in the dashboard with the Kubernetes metrics server to fix this issue. For more information, see https://github.com/kubernetes/dashboard/issues/3147 and https://github.com/kubernetes/dashboard/issues/2986.
When the dashboard project is updated to use the Kubernetes metrics server, this topic will be updated with information about how to restore the CPU and memory metrics functionality. Until that time, CPU and memory metrics are not visible in the dashboard on Amazon EKS cluster versions 1.11 and above.
There is a potential workaround posted on GitHub, but the Amazon EKS team has not evaluated the risk
Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources into a virtual network that you've defined. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS. For more information, see the Amazon VPC User Guide.
This topic guides you through creating a VPC for your cluster with either 3 public subnets, or two public subnets and two private subnets, which are provided with internet access through a NAT gateway. You can use this VPC for your Amazon EKS cluster. We recommend a network architecture that uses private subnets for your worker nodes, and public subnets for Kubernetes to create public load balancers within.
When you create an Amazon EKS cluster, you specify the Amazon VPC subnets for your cluster to use. Amazon EKS requires subnets in at least two Availability Zones. We recommend a network architecture that uses private subnets for your worker nodes and public subnets for Kubernetes to create internet-facing load balancers within.
When you create your cluster, specify all of the subnets that will host resources for your cluster (such as worker nodes and load balancers).
Note
Internet-facing load balancers require a public subnet in your cluster. Worker nodes also require outbound internet access to the Amazon EKS APIs for cluster introspection and node registration at launch time. To pull container images, they require access to the Amazon S3 and Amazon ECR APIs (and any other container registries, such as DockerHub). For more information, see Cluster Security Group Considerations and AWS IP Address Ranges in the AWS General Reference.
The subnets that you pass when you create the cluster influence where Amazon EKS places elastic network interfaces that are used for the control plane to worker node communication.
It is possible to specify only public or private subnets when you create your cluster, but there are some limitations associated with these configurations:
Private-only: Everything runs in a private subnet and Kubernetes cannot create internet-facing load balancers for your pods.
Public-only: Everything runs in a public subnet, including your worker nodes.
Amazon EKS creates an elastic network interface in your private subnets to facilitate communication to your worker nodes. This communication channel supports Kubernetes functionality such as kubectl exec and kubectl logs. The security group that you specify when you create your cluster is applied to the elastic network interfaces that are created for your cluster control plane.
Your VPC must have DNS hostname and DNS resolution support. Otherwise, your worker nodes cannot register with your cluster. For more information, see Using DNS with Your VPC in the Amazon VPC User Guide.
VPC IP Addressing
You can define both private (RFC 1918) and public (non-RFC 1918) CIDR ranges within the VPC used for your Amazon EKS cluster. For more information, see VPCs and Subnets and IP Addressing in Your VPC in the Amazon VPC User Guide.
The Amazon EKS control plane creates up to 4 cross-account elastic network interfaces in your VPC for each cluster. Be sure that the subnets you specify have enough available IP addresses for the cross-account elastic network interfaces and your pods.
Important
Docker runs in the 172.17.0.0/16 CIDR range in Amazon EKS clusters. We recommend that your cluster's VPC subnets do not overlap this range. Otherwise, you will receive the following error:
Error: : error upgrading connection: error dialing backend: dial tcp 172.17.nn.nn:10250: getsockopt: no route to host
VPC Tagging Requirement
When you create your Amazon EKS cluster, Amazon EKS tags the VPC containing the subnets you specify in the following way so that Kubernetes can discover it:
Key
Value
kubernetes.io/cluster/<cluster-name>
shared
Key: The <cluster-name> value matches your Amazon EKS cluster's name.
Value: The shared value allows more than one cluster to use this VPC.
Subnet Tagging Requirement
When you create your Amazon EKS cluster, Amazon EKS tags the subnets you specify in the following way so that Kubernetes can discover them:
Note
All subnets (public and private) that your cluster uses for resources should have this tag.
Key
Value
kubernetes.io/cluster/<cluster-name>
shared
Key: The <cluster-name> value matches your Amazon EKS cluster.
Value: The shared value allows more than one cluster to use this subnet.
Private Subnet Tagging Requirement for Internal Load Balancers
Private subnets in your VPC should be tagged accordingly so that Kubernetes knows that it can use them for internal load balancers:
Key
Value
kubernetes.io/role/internal-elb
1
Public Subnet Tagging Option for External Load Balancers
Public subnets in your VPC may be tagged accordingly so that Kubernetes knows to use only those subnets for external load balancers, instead of choosing a public subnet in each Availability Zone (in lexicographical order by subnet ID): </h4>
<h4> What Is AWS Lambda?
AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume - there is no charge when your code is not running. With AWS Lambda, you can run code for virtually any type of application or backend service - all with zero administration. AWS Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and logging. All you need to do is supply your code in one of the languages that AWS Lambda supports.
You can use AWS Lambda to run your code in response to events, such as changes to data in an Amazon S3 bucket or an Amazon DynamoDB table; to run your code in response to HTTP requests using Amazon API Gateway; or invoke your code using API calls made using AWS SDKs. With these capabilities, you can use Lambda to easily build data processing triggers for AWS services like Amazon S3 and Amazon DynamoDB, process streaming data stored in Kinesis, or create your own back end that operates at AWS scale, performance, and security.
You can also build serverless applications composed of functions that are triggered by events and automatically deploy them using CodePipeline and AWS CodeBuild. For more information, see AWS Lambda Applications.
For more information about the AWS Lambda execution environment, see AWS Lambda Runtimes. For information about how AWS Lambda determines compute resources required to execute your code, see AWS Lambda Function Configuration.
When Should I Use AWS Lambda?
AWS Lambda is an ideal compute platform for many application scenarios, provided that you can write your application code in languages supported by AWS Lambda, and run within the AWS Lambda standard runtime environment and resources provided by Lambda.
When using AWS Lambda, you are responsible only for your code. AWS Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources. This is in exchange for flexibility, which means you cannot log in to compute instances, or customize the operating system or language runtime. These constraints enable AWS Lambda to perform operational and administrative activities on your behalf, including provisioning capacity, monitoring fleet health, applying security patches, deploying your code, and monitoring and logging your Lambda functions.
If you need to manage your own compute resources, Amazon Web Services also offers other compute services to meet your needs.
Amazon Elastic Compute Cloud (Amazon EC2) service offers flexibility and a wide range of EC2 instance types to choose from. It gives you the option to customize operating systems, network and security settings, and the entire software stack, but you are responsible for provisioning capacity, monitoring fleet health and performance, and using Availability Zones for fault tolerance.
Elastic Beanstalk offers an easy-to-use service for deploying and scaling applications onto Amazon EC2 in which you retain ownership and full control over the underlying EC2 instances.
Lambda is a highly available service. For more information, see the AWS Lambda Service Level Agreement.
Are You a First-time User of AWS Lambda?
If you are a first-time user of AWS Lambda, we recommend that you read the following sections in order:
Read the product overview and watch the introductory video to understand sample use cases. These resources are available on the AWS Lambda webpage.
Try the console-based Getting Started exercise. The exercise provides instructions for you to create and test your first Lambda function using the console. You also learn about the programming model and other Lambda concepts. For more information, see Getting Started with AWS Lambda.
Read the Deploying Applications with AWS Lambda section of this guide. This section introduces various AWS Lambda components you work with to create an end-to-end experience.
Beyond the Getting Started exercise, you can explore the various use cases, each of which is provided with a tutorial that walks you through an example scenario. Depending on your application needs (for example, whether you want event driven Lambda function invocation or on-demand invocation), you can follow specific tutorials that meet your specific needs. For more information, see Using AWS Lambda with Other Services. </h4>
<p>For next steps, read the AWS CodePipeline Documentation.</p>
</div>
</body>
</html>