tration, is a highly popular technique utilized by development teams around the world to manage an exceedingly large number of containers.
[Devopedia](https://www.devopedia.org/) defines container orchestration as: “… a process that automates the deployment, management, scaling, networking, and availability of container-based applications.”
Container management involves a large number of tasks, such as provisioning, management, scaling and networking to name a few.
With an application with five containers, a development team may be able to manage these tasks efficiently; but a large application derives data from thousands of containers. Through orchestration, developers can automate various jobs that simplify the entire process.
An important point worth noting is that scheduling is often perceived as a part of the entire container management spectrum while some experts view it as a separate container principle.
According to [Microsoft](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications), *“Scheduling means to have the capability for an administrator to launch containers in a cluster so they also provide a UI.”*
A container scheduler has quite a few responsibilities from making the most efficient use of resources to ensuring effective load-balancing across different nodes or hosts. Due to their close proximity to the cluster, they are often treated the same.
In fact, popular container orchestration tools also provide scheduling capabilities.
### How Does It Work?
The first step to effectively orchestrate your containers is to identify the right tool. Notable names include Docker Swarm and Kubernetes, but we will get to them later.
First, let’s analyze how the application orchestration and scheduling process works:
* Once you have identified your orchestration tool, the next step involves describing the application’s configuration. This can be done in either a JSON or a YAML file.
* The configuration file serves an important purpose; it directs the container orchestration tool to the location where the images and the logs are stored. Furthermore, it also assists the tool with the process of how to mount storage volume and how to establish an intra-container network –this location is generally a private registry.
* The orchestration tool will further deploy these in a replicated group onto the host server. This ensures automatic scheduling of any new deployment that takes place within a cluster after checking for predefined prerequisites such as CPU memory requirements.
* Once deployed to the host, the orchestration tool ensures that the container’s lifecycle is managed using the conditions and provisions that were laid out in the configuration file.
Usually, development teams attempt to control the configuration files by deploying the same applications across a variety of testing environments before they are deployed into production.
With container orchestration tools, developers have the freedom to choose where they are deployed. These tools can be run on a variety of environments, ranging from on-premise servers and local machines to public cloud infrastructure providers.
## The Most Popular Application Scheduling And Orchestration Tools
There are quite a few application scheduling and orchestration tools that are available in the market, with each having their pros and cons. Here’s an overview of the top three that dominate the software development market:
### Kubernetes
Kubernetes has established itself as one of the benchmark orchestration tools in the software development industry. It traces its origins back to Google, starting off as an iteration to the search engine giant’s ‘[Borg project](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/).’
Additionally, it is also the centerpiece of the famed [Cloud Native Computing Foundation](https://www.cncf.io/) that is backed by computing powerhouses such as Google, Amazon Web Services, Microsoft, IBM, Intel, Redhat and
[Devopedia](https://www.devopedia.org/) defines container orchestration as: “… a process that automates the deployment, management, scaling, networking, and availability of container-based applications.”
Container management involves a large number of tasks, such as provisioning, management, scaling and networking to name a few.
With an application with five containers, a development team may be able to manage these tasks efficiently; but a large application derives data from thousands of containers. Through orchestration, developers can automate various jobs that simplify the entire process.
An important point worth noting is that scheduling is often perceived as a part of the entire container management spectrum while some experts view it as a separate container principle.
According to [Microsoft](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications), *“Scheduling means to have the capability for an administrator to launch containers in a cluster so they also provide a UI.”*
A container scheduler has quite a few responsibilities from making the most efficient use of resources to ensuring effective load-balancing across different nodes or hosts. Due to their close proximity to the cluster, they are often treated the same.
In fact, popular container orchestration tools also provide scheduling capabilities.
### How Does It Work?
The first step to effectively orchestrate your containers is to identify the right tool. Notable names include Docker Swarm and Kubernetes, but we will get to them later.
First, let’s analyze how the application orchestration and scheduling process works:
* Once you have identified your orchestration tool, the next step involves describing the application’s configuration. This can be done in either a JSON or a YAML file.
* The configuration file serves an important purpose; it directs the container orchestration tool to the location where the images and the logs are stored. Furthermore, it also assists the tool with the process of how to mount storage volume and how to establish an intra-container network –this location is generally a private registry.
* The orchestration tool will further deploy these in a replicated group onto the host server. This ensures automatic scheduling of any new deployment that takes place within a cluster after checking for predefined prerequisites such as CPU memory requirements.
* Once deployed to the host, the orchestration tool ensures that the container’s lifecycle is managed using the conditions and provisions that were laid out in the configuration file.
Usually, development teams attempt to control the configuration files by deploying the same applications across a variety of testing environments before they are deployed into production.
With container orchestration tools, developers have the freedom to choose where they are deployed. These tools can be run on a variety of environments, ranging from on-premise servers and local machines to public cloud infrastructure providers.
## The Most Popular Application Scheduling And Orchestration Tools
There are quite a few application scheduling and orchestration tools that are available in the market, with each having their pros and cons. Here’s an overview of the top three that dominate the software development market:
### Kubernetes
Kubernetes has established itself as one of the benchmark orchestration tools in the software development industry. It traces its origins back to Google, starting off as an iteration to the search engine giant’s ‘[Borg project](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/).’
Additionally, it is also the centerpiece of the famed [Cloud Native Computing Foundation](https://www.cncf.io/) that is backed by computing powerhouses such as Google, Amazon Web Services, Microsoft, IBM, Intel, Redhat and
devopedia.org
Home
For Developers. By Developers.
Cisco.
The hallmark of Kubernetes remains its ability to allow developers to deliver a PaaS (Platform-as-a-Service) that helps create a hardware abstraction layer while its ability to run across leading cloud platforms and on-premise servers is another plus point. This allows teams to move workloads easily across different platforms without having to invest in application redesign.
The main components of Kubernetes include:
* **Cluster:** A set of nodes typically headed by one master node. The other nodes (workers) can either be virtual machines or physical machines.
* **Kubernetes master:** Depending on defined policies, the master manages the application instances across all nodes – from deployment to scheduling.
* **Kubelet:** Each node runs an agent process called a Kubelet that derives all relevant information from the API server.
* **Pods:** The most basic unit that may consist of multiple containers located in the same host machine; each pod has a unique IP address.
* **Deployments**: A YAML object that describes the pods and the number of container instances
* **ReplicaSet**: The number of replicas you desire to run in a cluster can only be defined by a ReplicaSet. If a node running a pod fails, ReplicaSet can ensure scheduling on an available node.
### Docker Swarm
It is yet another popular orchestration tool, one that offers complete integration with Docker. Being less complex than Kubernetes, it makes for an excellent choice for developers who are just starting with container orchestration.
Simply put, Docker Swarm allows engineers to proceed with container deployments more easily and quickly due to the inherent integration with the platform. Nonetheless, [Dockers offer both](https://blogs.dxc.technology/2017/11/01/for-cloud-container-orchestration-its-all-kubernetes-all-the-time/) – its own orchestration tool ‘Swarm’ and Kubernetes – in the hope of making them complimentary.
The main components of Swarm include:
* **Swarm:** A set of nodes, usually accompanied by a master node. Each node denotes a machine, either virtual or physical.
* **Service:** Every task outlined by the administrator that is binding on the agent nodes is a service. It helps describe which container images will be utilized by the nodes and what commands will be executed in each container.
* **Manager Node**: As the name implies, the manager overlooks the delivery and the state of the swarm.
* **Worker Nodes**: The tasks distributed by the manager get picked up by the workers. Each node reports back to the master whereas the manager only keeps track of the tasks.
* **Task**: In the Docker environment, ‘tasks’ are containers that perform the commands that are outlined in the service. Once a worker has a task, it cannot be reassigned. Furthermore, if the task fails in the replica set, a new version of the task is assigned to the next available worker.
### Apache Mesos
Made in the University of California (Berkeley), Mesos has been around for longer than Kubernetes. It is famous as a lightweight application that provides developers with advanced scalability.
A typical Mesos’ can run more than 10,000 nodes – and that is excluding the frameworks it allows to evolve independently. Additionally, it provides support in a number of popular programming languages such as Java, C++ and Python.
It is important to note that Mesos only provides cluster management solutions. As such, developers have to build the entire framework to enable orchestration of a container – a popular example includes [Marathon](https://mesosphere.github.io/marathon/%5d).
Key components of Mesos include:
* **Master Daemon**: The master node that oversees worker nodes.
* **Agent** **Daemon**: Every task sent by the orchestration framework is completed by the Agent.
* **Framework**: The orchestration platform that enables it to receive resources from the cluster manager (Mesos) and sent tasks to be executed.
* **Offer**: The information pertaining to agent nodes that is sent via Mesos to the orchestration framework.
* **Task**: The work that needs to be done based o
The hallmark of Kubernetes remains its ability to allow developers to deliver a PaaS (Platform-as-a-Service) that helps create a hardware abstraction layer while its ability to run across leading cloud platforms and on-premise servers is another plus point. This allows teams to move workloads easily across different platforms without having to invest in application redesign.
The main components of Kubernetes include:
* **Cluster:** A set of nodes typically headed by one master node. The other nodes (workers) can either be virtual machines or physical machines.
* **Kubernetes master:** Depending on defined policies, the master manages the application instances across all nodes – from deployment to scheduling.
* **Kubelet:** Each node runs an agent process called a Kubelet that derives all relevant information from the API server.
* **Pods:** The most basic unit that may consist of multiple containers located in the same host machine; each pod has a unique IP address.
* **Deployments**: A YAML object that describes the pods and the number of container instances
* **ReplicaSet**: The number of replicas you desire to run in a cluster can only be defined by a ReplicaSet. If a node running a pod fails, ReplicaSet can ensure scheduling on an available node.
### Docker Swarm
It is yet another popular orchestration tool, one that offers complete integration with Docker. Being less complex than Kubernetes, it makes for an excellent choice for developers who are just starting with container orchestration.
Simply put, Docker Swarm allows engineers to proceed with container deployments more easily and quickly due to the inherent integration with the platform. Nonetheless, [Dockers offer both](https://blogs.dxc.technology/2017/11/01/for-cloud-container-orchestration-its-all-kubernetes-all-the-time/) – its own orchestration tool ‘Swarm’ and Kubernetes – in the hope of making them complimentary.
The main components of Swarm include:
* **Swarm:** A set of nodes, usually accompanied by a master node. Each node denotes a machine, either virtual or physical.
* **Service:** Every task outlined by the administrator that is binding on the agent nodes is a service. It helps describe which container images will be utilized by the nodes and what commands will be executed in each container.
* **Manager Node**: As the name implies, the manager overlooks the delivery and the state of the swarm.
* **Worker Nodes**: The tasks distributed by the manager get picked up by the workers. Each node reports back to the master whereas the manager only keeps track of the tasks.
* **Task**: In the Docker environment, ‘tasks’ are containers that perform the commands that are outlined in the service. Once a worker has a task, it cannot be reassigned. Furthermore, if the task fails in the replica set, a new version of the task is assigned to the next available worker.
### Apache Mesos
Made in the University of California (Berkeley), Mesos has been around for longer than Kubernetes. It is famous as a lightweight application that provides developers with advanced scalability.
A typical Mesos’ can run more than 10,000 nodes – and that is excluding the frameworks it allows to evolve independently. Additionally, it provides support in a number of popular programming languages such as Java, C++ and Python.
It is important to note that Mesos only provides cluster management solutions. As such, developers have to build the entire framework to enable orchestration of a container – a popular example includes [Marathon](https://mesosphere.github.io/marathon/%5d).
Key components of Mesos include:
* **Master Daemon**: The master node that oversees worker nodes.
* **Agent** **Daemon**: Every task sent by the orchestration framework is completed by the Agent.
* **Framework**: The orchestration platform that enables it to receive resources from the cluster manager (Mesos) and sent tasks to be executed.
* **Offer**: The information pertaining to agent nodes that is sent via Mesos to the orchestration framework.
* **Task**: The work that needs to be done based o
n resource offers.
## Benefits Of Application Orchestration Tools
Ultimately, orchestration tools take on many processes that would previously keep the developers occupied; with these, resources can be dedicated to more important tasks.
Here are some of the benefits of application orchestration tools:
#### Transportability
Modern tools allow specific application components to be scaled without affecting the rest of the application.
#### Rapid Deployment
Faced with increased traffic? Orchestration tools can assist you in the quick creation of new containerized applications.
#### Improved Efficiency
By automating several core tasks, you are reducing the probability of human errors. With such a simplified installation process, your software development team experiences a rise in productivity.
#### Highly Secure
With the containerization of applications, these tools allow you to share resources without risking the security of your data.
The software development industry has quickly moved to embrace the container model as it allows them to streamline the entire deployment process. But the success of software containers has been boosted in no small part by the advent of advanced orchestration tools that allow users to automate container management.
While Kubernetes continues to dominate the industry, there are many other tools with different advantages as well. Ultimately, the right option for you depends on your requirements and what tools can meet them best.
https://redd.it/fcc09f
@r_devops
## Benefits Of Application Orchestration Tools
Ultimately, orchestration tools take on many processes that would previously keep the developers occupied; with these, resources can be dedicated to more important tasks.
Here are some of the benefits of application orchestration tools:
#### Transportability
Modern tools allow specific application components to be scaled without affecting the rest of the application.
#### Rapid Deployment
Faced with increased traffic? Orchestration tools can assist you in the quick creation of new containerized applications.
#### Improved Efficiency
By automating several core tasks, you are reducing the probability of human errors. With such a simplified installation process, your software development team experiences a rise in productivity.
#### Highly Secure
With the containerization of applications, these tools allow you to share resources without risking the security of your data.
The software development industry has quickly moved to embrace the container model as it allows them to streamline the entire deployment process. But the success of software containers has been boosted in no small part by the advent of advanced orchestration tools that allow users to automate container management.
While Kubernetes continues to dominate the industry, there are many other tools with different advantages as well. Ultimately, the right option for you depends on your requirements and what tools can meet them best.
https://redd.it/fcc09f
@r_devops
reddit
Introduction to Application Scheduling & Orchestration
One of the hallmarks of a cloud native application is that it features high resilience against errors while providing a number of scalability...
Logging all Pull Requests / Merge Requests for audit purposes
Hi guys, we are in the process of adopting CI/CD at our company and want to work using Merge Requests. This is quite a new area in our company. In order to allow people to go to production automatically, we want to use the Merge Request feature in GitLab. In the Merge Request, approvals are given and before the Merge Request the corresponding pipeline result is displayed.
For audit purposes, is it a good idea to store these Merge Requests somewhere? Because, would it be possible for someone to overwrite the git history locally, and then let someone else merge that in?
How do other devops folks in this subreddit handle auditing their Merge Requests?
Additionally, is it a good idea to store the corresponding build logs that result from the pipeline run following the merging of the Merge Request? Audit wants to see if a change was succesfull or not.
Really appreciating your input here..
https://redd.it/fce6i2
@r_devops
Hi guys, we are in the process of adopting CI/CD at our company and want to work using Merge Requests. This is quite a new area in our company. In order to allow people to go to production automatically, we want to use the Merge Request feature in GitLab. In the Merge Request, approvals are given and before the Merge Request the corresponding pipeline result is displayed.
For audit purposes, is it a good idea to store these Merge Requests somewhere? Because, would it be possible for someone to overwrite the git history locally, and then let someone else merge that in?
How do other devops folks in this subreddit handle auditing their Merge Requests?
Additionally, is it a good idea to store the corresponding build logs that result from the pipeline run following the merging of the Merge Request? Audit wants to see if a change was succesfull or not.
Really appreciating your input here..
https://redd.it/fce6i2
@r_devops
reddit
Logging all Pull Requests / Merge Requests for audit purposes
Hi guys, we are in the process of adopting CI/CD at our company and want to work using Merge Requests. This is quite a new area in our company. In...
What sounds better to a prospective employer?
I have received a job offer today, but I had a final stage interview last Friday with a company I like more.
Which of these e-mails would sound better?
​
> May I ask at what stage is the review of my interview? I have received other offers as well and would Like to know about my application as well at your company so I can fully review my offers in order to let everyone know my next step.
​
>My job search has reached the offer stage with my other applications. Can you let me know when you are planning to update as to the status of my application, so that I can fully evaluate my options.
https://redd.it/fcbvva
@r_devops
I have received a job offer today, but I had a final stage interview last Friday with a company I like more.
Which of these e-mails would sound better?
​
> May I ask at what stage is the review of my interview? I have received other offers as well and would Like to know about my application as well at your company so I can fully review my offers in order to let everyone know my next step.
​
>My job search has reached the offer stage with my other applications. Can you let me know when you are planning to update as to the status of my application, so that I can fully evaluate my options.
https://redd.it/fcbvva
@r_devops
reddit
What sounds better to a prospective employer?
I have received a job offer today, but I had a final stage interview last Friday with a company I like more. Which of these e-mails would sound...
Is there a way to make Jest reuse cache when working in a different directory?
We use Jest in our CI pipelines. The tests take about 5 minutes to complete with no cache and about 20 seconds to complete with cache.
We are using Jenkins with multi-branch so a different folder is used for basically every job that is run. I've noticed with Jest that it knows what folder you are running from and creates a unique cache dir in /tmp/jest_XX/jest-transform-cache-2e21483d6fe4693e52e5df028952xxxxxxxx
If you are running the tests from the same folder the cache is reused but if you even do so much as rename your work folder a new directory in /tmp/jest_XX/ is created from scratch when jest is run again.
This essentially means that every single pipeline run in Jenkins is not re-using jest cache so unit tests take ~5 minutes.
https://redd.it/fcedxa
@r_devops
We use Jest in our CI pipelines. The tests take about 5 minutes to complete with no cache and about 20 seconds to complete with cache.
We are using Jenkins with multi-branch so a different folder is used for basically every job that is run. I've noticed with Jest that it knows what folder you are running from and creates a unique cache dir in /tmp/jest_XX/jest-transform-cache-2e21483d6fe4693e52e5df028952xxxxxxxx
If you are running the tests from the same folder the cache is reused but if you even do so much as rename your work folder a new directory in /tmp/jest_XX/ is created from scratch when jest is run again.
This essentially means that every single pipeline run in Jenkins is not re-using jest cache so unit tests take ~5 minutes.
https://redd.it/fcedxa
@r_devops
reddit
Is there a way to make Jest reuse cache when working in a...
We use Jest in our CI pipelines. The tests take about 5 minutes to complete with no cache and about 20 seconds to complete with cache. We are...
[Issue] Unable to access vrops after DNS and IP changed
Hi guys. need some help as I have been working this issue for the last 3 to 4 days.
History: We changed location which prompt the need for new IP and DNS, so I updated the IP and DNS via following method: `/opt/vmware/share/vami/vami_config_net`
The menu allowed me to reconfigued the IP and DNS. Next, I deleted the tomcat ./work/Catalina/localhost folder then restarted tomcat.
Still not able to bring up the login spash screen for the `https://{ip}/admin`
I verified I am able to ping the ip and resolve the DNS from the vm and from my local machine.
Can someone help if they exprienced this issue before or reconfigured the IP and DNS and what else did you do?
​
Thanks ahead.
https://redd.it/fchcx6
@r_devops
Hi guys. need some help as I have been working this issue for the last 3 to 4 days.
History: We changed location which prompt the need for new IP and DNS, so I updated the IP and DNS via following method: `/opt/vmware/share/vami/vami_config_net`
The menu allowed me to reconfigued the IP and DNS. Next, I deleted the tomcat ./work/Catalina/localhost folder then restarted tomcat.
Still not able to bring up the login spash screen for the `https://{ip}/admin`
I verified I am able to ping the ip and resolve the DNS from the vm and from my local machine.
Can someone help if they exprienced this issue before or reconfigured the IP and DNS and what else did you do?
​
Thanks ahead.
https://redd.it/fchcx6
@r_devops
reddit
[Issue] Unable to access vrops after DNS and IP changed
Hi guys. need some help as I have been working this issue for the last 3 to 4 days. History: We changed location which prompt the need for new...
What are some good companies with full-time remote Cloud Engineer type jobs that I can apply for?
https://redd.it/fccgjl
@r_devops
https://redd.it/fccgjl
@r_devops
reddit
What are some good companies with full-time remote Cloud Engineer...
Posted in r/devops by u/badger-on-parade • 1 point and 1 comment
Where do devops engineers look for job postings online?
Apart from Indeed and similar generic job sites, if I have a devops position available, where should I post it?
\[edit\] Followup: any tips on how I reach devops engineers who may not necessarily be searching for a job, but who might be interested in the position I have open? StackOverflow jobs?
https://redd.it/fcfiit
@r_devops
Apart from Indeed and similar generic job sites, if I have a devops position available, where should I post it?
\[edit\] Followup: any tips on how I reach devops engineers who may not necessarily be searching for a job, but who might be interested in the position I have open? StackOverflow jobs?
https://redd.it/fcfiit
@r_devops
reddit
Where do devops engineers look for job postings online?
Apart from Indeed and similar generic job sites, if I have a devops position available, where should I post it? \[edit\] Followup: any tips on...
Is there a sensible way to link Terraform and Ansible?
Use-case is provisioning a web server host (Terraform - EC2/AWS) and then applying its latest configuration (ansible).
Terraform warn/advise against using their "provisioners", so I am reluctant to use Terraform to copy the files. The web server config is also subject to change regularly, hence not wanting to bake it into the disk/AMI image.
Ansible is good for this because it will ensure all the packages are installed/running and keep the server configs in sync/updated.
The host, when ready, also needs to be added to a loadbalancer target group when done, so would be something like:
1. Create host(s) with Terraform
2. Apply config with ansible
3. Add host to target group (with terraform/manually?)
Is there a better way to approach this that I'm probably missing?
Kinda feels clunking trying to do infrastructure-as-code but having to use two separate tools like this.
https://redd.it/fcjx2t
@r_devops
Use-case is provisioning a web server host (Terraform - EC2/AWS) and then applying its latest configuration (ansible).
Terraform warn/advise against using their "provisioners", so I am reluctant to use Terraform to copy the files. The web server config is also subject to change regularly, hence not wanting to bake it into the disk/AMI image.
Ansible is good for this because it will ensure all the packages are installed/running and keep the server configs in sync/updated.
The host, when ready, also needs to be added to a loadbalancer target group when done, so would be something like:
1. Create host(s) with Terraform
2. Apply config with ansible
3. Add host to target group (with terraform/manually?)
Is there a better way to approach this that I'm probably missing?
Kinda feels clunking trying to do infrastructure-as-code but having to use two separate tools like this.
https://redd.it/fcjx2t
@r_devops
reddit
Is there a sensible way to link Terraform and Ansible?
Use-case is provisioning a web server host (Terraform - EC2/AWS) and then applying its latest configuration (ansible). Terraform...
Stackstorm on Openshift
Hey y'all, hoping someone here can help me out a bit. I'm trying to get a poc going of stackstorm as I think the workflows and automation capabilities could be extremely useful for my team. I plan on integrating it with our chatbot too. Catch is that we run on openshift currently and the stackstorm container expects to run on root. Anyone have any experience with a situation like this?
For context, I dont have cluster admin privs so I can't alter the ssc
https://redd.it/fcfyag
@r_devops
Hey y'all, hoping someone here can help me out a bit. I'm trying to get a poc going of stackstorm as I think the workflows and automation capabilities could be extremely useful for my team. I plan on integrating it with our chatbot too. Catch is that we run on openshift currently and the stackstorm container expects to run on root. Anyone have any experience with a situation like this?
For context, I dont have cluster admin privs so I can't alter the ssc
https://redd.it/fcfyag
@r_devops
reddit
Stackstorm on Openshift
Hey y'all, hoping someone here can help me out a bit. I'm trying to get a poc going of stackstorm as I think the workflows and automation...
Error Aggregation from Kinesis stream
Hi people,
​
We have an existing observability pipeline where applications log to Cloudwatch, and our logs flow into Kinesis. Developers are asking for an error management tool, eg. Sentry or Rollbar etc.
​
Has anyone got prior art for plugging into one of these tools with API integration only from a Lambda function?
https://redd.it/fcfpxl
@r_devops
Hi people,
​
We have an existing observability pipeline where applications log to Cloudwatch, and our logs flow into Kinesis. Developers are asking for an error management tool, eg. Sentry or Rollbar etc.
​
Has anyone got prior art for plugging into one of these tools with API integration only from a Lambda function?
https://redd.it/fcfpxl
@r_devops
reddit
Error Aggregation from Kinesis stream
Hi people, We have an existing observability pipeline where applications log to Cloudwatch, and our logs flow into Kinesis. Developers...
How to monitor WordPress contact form to AWS SES connection?
Hi all,
tldr; how to monitor a connection between website contact form and SES to see if it’s logged in.
Non-profit marketing guy and non-programmer here. We ran into a situation recently where our our WordPress website contact forms, which send email notifications via AWS SES lost their authentication/connection and to both the person filling out the form and us, it looked like everything was working fine.
It took a us awhile to figure out that the connection was lost and we don’t want to run into that situation. Without scrapping the whole system for something else, I’m looking for advice on how we can monitor and get alerts if the connection is lost.
Right now we’re manually and randomly filling out contact forms to see if they’re working, which is driving our program staff bonkers and wasting our own time.
I know in the AWS SES backend we can see number of emails sent, delivered, bounced, etc but without a baseline of how many sent per day, we can’t really use that to monitor connectivity. Sometimes we get no contact form submissions, and some days it’s hundreds of legit requests.
I’ve seen that there are APM services out there that can fill out forms and look for a response like hitting a goal page, but how could it look for an email getting triggered and sent unless it could maybe receive an inbound email? I just don’t know enough about how to see what these can do.
We have a some money to solve this and access to developers who with instructions could install anything necessary but I figured I’d ask here before I went to the guys our IT department recommended at $300/hr for discovery.
Thank you and happy to answer any questions that might be helpful.
https://redd.it/fcmr41
@r_devops
Hi all,
tldr; how to monitor a connection between website contact form and SES to see if it’s logged in.
Non-profit marketing guy and non-programmer here. We ran into a situation recently where our our WordPress website contact forms, which send email notifications via AWS SES lost their authentication/connection and to both the person filling out the form and us, it looked like everything was working fine.
It took a us awhile to figure out that the connection was lost and we don’t want to run into that situation. Without scrapping the whole system for something else, I’m looking for advice on how we can monitor and get alerts if the connection is lost.
Right now we’re manually and randomly filling out contact forms to see if they’re working, which is driving our program staff bonkers and wasting our own time.
I know in the AWS SES backend we can see number of emails sent, delivered, bounced, etc but without a baseline of how many sent per day, we can’t really use that to monitor connectivity. Sometimes we get no contact form submissions, and some days it’s hundreds of legit requests.
I’ve seen that there are APM services out there that can fill out forms and look for a response like hitting a goal page, but how could it look for an email getting triggered and sent unless it could maybe receive an inbound email? I just don’t know enough about how to see what these can do.
We have a some money to solve this and access to developers who with instructions could install anything necessary but I figured I’d ask here before I went to the guys our IT department recommended at $300/hr for discovery.
Thank you and happy to answer any questions that might be helpful.
https://redd.it/fcmr41
@r_devops
reddit
How to monitor WordPress contact form to AWS SES connection?
Hi all, tldr; how to monitor a connection between website contact form and SES to see if it’s logged in. Non-profit marketing guy and...
AWS Elasticsearch Service Security
Hello,
I was curious if anyone has used the public facing Elasticsearch Service? I was curious of how secure it actually is (ex: would you funnel customer data through it?). For instance, if I had all the users authenticate into Kibana via SAML/Cognito and have my ec2 instances only able to PUT/POST data to it (access policy example below). How secure would that be?
Is there a better way to handle this if not? I have tried the VPC method, but I always have issues with allow open access to the VPC(?) domain and still requiring users to login.
Open to suggestions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"es:ESHttpPost",
"es:ESHttpPatch",
"es:ESHttpPut"
],
"Resource": "arn:${Partition}:es:${Region}:${Account}:domain/${DomainName}/*",
"Condition": {"IpAddress": {"aws:SourceIp": "123.45.67.0/21"}} # VPC CIDR RANGE
]
}
https://redd.it/fccaub
@r_devops
Hello,
I was curious if anyone has used the public facing Elasticsearch Service? I was curious of how secure it actually is (ex: would you funnel customer data through it?). For instance, if I had all the users authenticate into Kibana via SAML/Cognito and have my ec2 instances only able to PUT/POST data to it (access policy example below). How secure would that be?
Is there a better way to handle this if not? I have tried the VPC method, but I always have issues with allow open access to the VPC(?) domain and still requiring users to login.
Open to suggestions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"es:ESHttpPost",
"es:ESHttpPatch",
"es:ESHttpPut"
],
"Resource": "arn:${Partition}:es:${Region}:${Account}:domain/${DomainName}/*",
"Condition": {"IpAddress": {"aws:SourceIp": "123.45.67.0/21"}} # VPC CIDR RANGE
]
}
https://redd.it/fccaub
@r_devops
reddit
AWS Elasticsearch Service Security
Hello, I was curious if anyone has used the public facing Elasticsearch Service? I was curious of how secure it actually is (ex: would you...
How we optimised our build system using umake
Over the past few months we worked on a project to improve our build times. We wanted to replace our makefile based build with something modern and fast. We compared multiple tools such as google bazel, facebook buck, ninja and plain old cmake. At the end of the day we figured that none of them matched our exact needs.
Eventually we reached tup, which looked very promising. The issue with tup was the lack of strong remote caching. Initially we wanted to improve tup to match our needs. After a while we figured that we should just build something new. With all the good stuff that we took from tup and strong caching like sccache from mozzila. The result was a brand new tool - umake. It is fast (really fast), easy to use and correct. No more building the same binary in the office if someone else already built it. No more running make -j10 and getting broken results. It just works, and it works fast.
I'll be happy to hear your thoughts on the topic.
For more details check out: https://drivenets.com/blog/the-inside-story-of-how-we-optimized-our-own-build-system/ https://github.com/grisha85/umake/
https://redd.it/fcbelt
@r_devops
Over the past few months we worked on a project to improve our build times. We wanted to replace our makefile based build with something modern and fast. We compared multiple tools such as google bazel, facebook buck, ninja and plain old cmake. At the end of the day we figured that none of them matched our exact needs.
Eventually we reached tup, which looked very promising. The issue with tup was the lack of strong remote caching. Initially we wanted to improve tup to match our needs. After a while we figured that we should just build something new. With all the good stuff that we took from tup and strong caching like sccache from mozzila. The result was a brand new tool - umake. It is fast (really fast), easy to use and correct. No more building the same binary in the office if someone else already built it. No more running make -j10 and getting broken results. It just works, and it works fast.
I'll be happy to hear your thoughts on the topic.
For more details check out: https://drivenets.com/blog/the-inside-story-of-how-we-optimized-our-own-build-system/ https://github.com/grisha85/umake/
https://redd.it/fcbelt
@r_devops
DriveNets
The Inside Story of How We Optimized our Own Build System - DriveNets
The story of the DriveNets build system started like most other startups. We took various different open source projects as a base for the product. Almost every one of them had a different way of building it. From plain old Makefiles to automake, CMake and…
How do you usually deal with versioning of helm charts?
There are 2 approaches that I want to ask about:
1 - Increment versions of components inside the chart code and every time you do it generate new chart version
2 - Update versions by supplying local values via parameters or value file on the instance itself - this way chart version remains unchanged
Approach 2 does not contradict the first one, but trying to use both at the same time looks a little messy.
Would appreciate thoughts on this.
https://redd.it/fcol46
@r_devops
There are 2 approaches that I want to ask about:
1 - Increment versions of components inside the chart code and every time you do it generate new chart version
2 - Update versions by supplying local values via parameters or value file on the instance itself - this way chart version remains unchanged
Approach 2 does not contradict the first one, but trying to use both at the same time looks a little messy.
Would appreciate thoughts on this.
https://redd.it/fcol46
@r_devops
reddit
r/devops - How do you usually deal with versioning of helm charts?
0 votes and 1 comment so far on Reddit
Need help with cloudformation
{
"Parameters": {
"redisboxes": {
"Type": "String",
"Default": "2",
"Description": "launch 2 boxes"
}
},
"InstanceType": {
"Description": "Select one of the possible instance types",
"Type": "String",
"Default": "t2.micro",
"AllowedValues": ["t2.micro", "t2.small", "t2.medium"]
},
"Outputs": {
"LoadBalancerIP": {
"Value": {
"Ref": "LoadBalancerIP"
}
}
},
"Resources": {
"VPC": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "10.0.0.0/16",
"EnableDnsHostnames": true
}
},
"VPCGateway": {
"Type": "AWS::EC2::VPCGatewayAttachment",
"Properties": {
"InternetGatewayId": {
"Ref": "Gateway"
},
"VpcId": {
"Ref": "VPC"
}
}
},
"PublicSubnet": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.0.0/24",
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateSubnet": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.1.0/24",
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateSubnetRoute": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "PrivateRouteTable"
},
"SubnetId": {
"Ref": "PrivateSubnet"
}
}
},
"PrivateRouteTable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateRouteGlobal": {
"Type": "AWS::EC2::Route",
"Properties": {
"RouteTableId": {
"Ref": "PrivateRouteTable"
},
"DestinationCidrBlock": "0.0.0.0/0",
"InstanceId": {
"Ref": "NATDevice"
}
},
"DependsOn": "PublicRouteGlobal"
},
"PublicSubnetRoute": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "PublicRouteTable"
},
"SubnetId": {
"Ref": "PublicSubnet"
}
}
},
"PublicRouteTable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"PublicRouteGlobal": {
"Type": "AWS::EC2::Route",
"Properties": {
"RouteTableId": {
"Ref": "PublicRouteTable"
},
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": {
"Ref": "Gateway"
}
}
},
"NATIPAddress": {
"Type": "AWS::EC2::EIP",
"Properties": {
"Domain": "vpc",
"InstanceId": {
"Ref": "NATDevice"
}
},
"DependsOn": "VPCGateway"
},
"NATDevice": {
"Type": "AWS::EC2::Instance",
"Properties": {
"SubnetId": {
"Ref": "PublicSubnet"
},
"SourceDestCheck": "false",
"ImageId": {
"Fn::FindInMap": ["AWSNATAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroup"
}],
"Tags": [{
"Key": "Name",
"Value": "Serf Demo NAT Device"
}]
}
},
"LoadBalancer": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId": {
"Fn::FindInMap": ["AWSINSTAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"PrivateIpAddress": "10.0.0.5",
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroup"
}],
"SubnetId": {
"Ref": "PublicSubnet"
},
"Tags": [{
"Key": "Name",
"Value": "Serf Demo LB"
}],
"UserData": "IyEvYmluL3NoCgpzZXQgLWUKCiMgSW5zdGFsbCBIQVBy
{
"Parameters": {
"redisboxes": {
"Type": "String",
"Default": "2",
"Description": "launch 2 boxes"
}
},
"InstanceType": {
"Description": "Select one of the possible instance types",
"Type": "String",
"Default": "t2.micro",
"AllowedValues": ["t2.micro", "t2.small", "t2.medium"]
},
"Outputs": {
"LoadBalancerIP": {
"Value": {
"Ref": "LoadBalancerIP"
}
}
},
"Resources": {
"VPC": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "10.0.0.0/16",
"EnableDnsHostnames": true
}
},
"VPCGateway": {
"Type": "AWS::EC2::VPCGatewayAttachment",
"Properties": {
"InternetGatewayId": {
"Ref": "Gateway"
},
"VpcId": {
"Ref": "VPC"
}
}
},
"PublicSubnet": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.0.0/24",
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateSubnet": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.1.0/24",
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateSubnetRoute": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "PrivateRouteTable"
},
"SubnetId": {
"Ref": "PrivateSubnet"
}
}
},
"PrivateRouteTable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"PrivateRouteGlobal": {
"Type": "AWS::EC2::Route",
"Properties": {
"RouteTableId": {
"Ref": "PrivateRouteTable"
},
"DestinationCidrBlock": "0.0.0.0/0",
"InstanceId": {
"Ref": "NATDevice"
}
},
"DependsOn": "PublicRouteGlobal"
},
"PublicSubnetRoute": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "PublicRouteTable"
},
"SubnetId": {
"Ref": "PublicSubnet"
}
}
},
"PublicRouteTable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"PublicRouteGlobal": {
"Type": "AWS::EC2::Route",
"Properties": {
"RouteTableId": {
"Ref": "PublicRouteTable"
},
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": {
"Ref": "Gateway"
}
}
},
"NATIPAddress": {
"Type": "AWS::EC2::EIP",
"Properties": {
"Domain": "vpc",
"InstanceId": {
"Ref": "NATDevice"
}
},
"DependsOn": "VPCGateway"
},
"NATDevice": {
"Type": "AWS::EC2::Instance",
"Properties": {
"SubnetId": {
"Ref": "PublicSubnet"
},
"SourceDestCheck": "false",
"ImageId": {
"Fn::FindInMap": ["AWSNATAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroup"
}],
"Tags": [{
"Key": "Name",
"Value": "Serf Demo NAT Device"
}]
}
},
"LoadBalancer": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId": {
"Fn::FindInMap": ["AWSINSTAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"PrivateIpAddress": "10.0.0.5",
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroup"
}],
"SubnetId": {
"Ref": "PublicSubnet"
},
"Tags": [{
"Key": "Name",
"Value": "Serf Demo LB"
}],
"UserData": "IyEvYmluL3NoCgpzZXQgLWUKCiMgSW5zdGFsbCBIQVBy
b3h5CnN1ZG8gYXB0LWdldCB1cGRhdGUKc3VkbyBhcHQtZ2V0IGluc3RhbGwgLXkgaGFwcm94eQoKIyBDb25maWd1cmUgaXQgaW4gYSBqYW5rIHdheQpjYXQgPDxFT0YgPi90bXAvaGFwcm94eS5jZmcKZ2xvYmFsCiAgICBkYWVtb24KICAgIG1heGNvbm4gMjU2CgpkZWZhdWx0cwogICAgbW9kZSBodHRwCiAgICB0aW1lb3V0IGNvbm5lY3QgNTAwMG1zCiAgICB0aW1lb3V0IGNsaWVudCA1MDAwMG1zCiAgICB0aW1lb3V0IHNlcnZlciA1MDAwMG1zCgpsaXN0ZW4gc3RhdHMKICAgIGJpbmQgKjo5OTk5CiAgICBtb2RlIGh0dHAKICAgIHN0YXRzIGVuYWJsZQogICAgc3RhdHMgdXJpIC8KICAgIHN0YXRzIHJlZnJlc2ggMnMKCiNsaXN0ZW4gaHR0cC1pbgojICAgIGJpbmQgKjo4MAojICAgIGJhbGFuY2Ugcm91bmRyb2JpbgojICAgIG9wdGlvbiBodHRwLXNlcnZlci1jbG9zZQoKZnJvbnRlbmQgcmVkaXMKICBiaW5kIDEyNy4wLjAuMTo1MDAwIG5hbWUgcmVkaXMKICBkZWZhdWx0X2JhY2tlbmQgcmVkaXNfc2VydmVycwogIG1heGNvbm4gMTAyNAoKYmFja2VuZCByZWRpc19zZXJ2ZXJzCiAgYmFsYW5jZSByb3VuZHJvYmluCiAgI29wdGlvbiB0Y3AtY2hlY2sKICAjdGNwLWNoZWNrIGNvbm5lY3QKICAjdGNwLWNoZWNrIHNlbmQgUElOR1xyXG4KICAjdGNwLWNoZWNrIGV4cGVjdCBzdHJpbmcgK1BPTkcKICAjdGNwLWNoZWNrIHNlbmQgUVVJVFxyXG4KICAjdGNwLWNoZWNrIGV4cGVjdCBzdHJpbmcgK09LCiAgI3NlcnZlciByZWRpc183MDAwIGxvY2FsaG9zdDo3MDAwIGNoZWNrIGludGVyIDFzIHdlaWdodCA3NwogICNzZXJ2ZXIgcmVkaXNfNzAwMSBsb2NhbGhvc3Q6NzAwMSBjaGVjayBpbnRlciAxcyB3ZWlnaHQgMzMKCkVPRgpzdWRvIG12IC90bXAvaGFwcm94eS5jZmcgL2V0Yy9oYXByb3h5L2hhcHJveHkuY2ZnCgojIEVuYWJsZSBIQVByb3h5CmNhdCA8PEVPRiA+L3RtcC9oYXByb3h5CkVOQUJMRUQ9MQpFT0YKc3VkbyBtdiAvdG1wL2hhcHJveHkgL2V0Yy9kZWZhdWx0L2hhcHJveHkKCiMgU3RhcnQgaXQKc3VkbyAvZXRjL2luaXQuZC9oYXByb3h5IHN0YXJ0CgpleHBvcnQgU0VSRl9ST0xFPSJsYiIKCgpzZXQgLWUKCnN1ZG8gYXB0LWdldCBpbnN0YWxsIC15IHVuemlwCgpjZCAvdG1wCnVudGlsIHdnZXQgLU8gc2VyZi56aXAgaHR0cHM6Ly9kbC5iaW50cmF5LmNvbS9taXRjaGVsbGgvc2VyZi8wLjYuNF9saW51eF9hbWQ2NC56aXA7IGRvCiAgICBzbGVlcCAxCmRvbmUKdW56aXAgc2VyZi56aXAKc3VkbyBtdiBzZXJmIC91c3IvbG9jYWwvYmluL3NlcmYKCiMgVGhlIG1lbWJlciBqb2luIHNjcmlwdCBpcyBpbnZva2VkIHdoZW4gYSBtZW1iZXIgam9pbnMgdGhlIFNlcmYgY2x1c3Rlci4KIyBPdXIgam9pbiBzY3JpcHQgc2ltcGx5IGFkZHMgdGhlIG5vZGUgdG8gdGhlIGxvYWQgYmFsYW5jZXIuCmNhdCA8PEVPRiA+L3RtcC9qb2luLnNoCmlmIFsgInhcJHtTRVJGX1RBR19ST0xFfSIgIT0gInhsYiIgXTsgdGhlbgogICAgZWNobyAiTm90IGFuIGxiLiBJZ25vcmluZyBtZW1iZXIgam9pbi4iCiAgICBleGl0IDAKZmkKd2hpbGUgcmVhZCBsaW5lOyBkbwogICAgUk9MRT1cYGVjaG8gXCRsaW5lIHwgYXdrICd7cHJpbnQgXFxcJDMgfSdcYAogICAgaWYgWyAieFwke1JPTEV9IiAhPSAieHdlYiIgXTsgdGhlbgogICAgICAgIGNvbnRpbnVlCiAgICBmaQogICAgZWNobyBcJGxpbmUgfCBcXAogICAgICAgIGF3ayAneyBwcmludGYgIiAgICBzZXJ2ZXIgJXMgJXMgY2hlY2tcXG4iLCBcJDEsIFwkMiB9JyA+Pi9ldGMvaGFwcm94eS9oYXByb3h5LmNmZwpkb25lCi9ldGMvaW5pdC5kL2hhcHJveHkgcmVsb2FkCkVPRgpzdWRvIG12IC90bXAvam9pbi5zaCAvdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9qb2luLnNoCmNobW9kICt4IC91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2pvaW4uc2gKCiMgVGhlIG1lbWJlciBsZWF2ZSBzY3JpcHQgaXMgaW52b2tlZCB3aGVuIGEgbWVtYmVyIGxlYXZlcyBvciBmYWlscyBvdXQKIyBvZiB0aGUgc2VyZiBjbHVzdGVyLiBPdXIgc2NyaXB0IHJlbW92ZXMgdGhlIG5vZGUgZnJvbSB0aGUgbG9hZCBiYWxhbmNlci4KY2F0IDw8RU9GID4vdG1wL2xlYXZlLnNoCmlmIFsgInhcJHtTRVJGX1RBR19ST0xFfSIgIT0gInhsYiIgXTsgdGhlbgogICAgZWNobyAiTm90IGFuIGxiLiBJZ25vcmluZyBtZW1iZXIgbGVhdmUiCiAgICBleGl0IDAKZmkKd2hpbGUgcmVhZCBsaW5lOyBkbwogICAgTkFNRT1cYGVjaG8gXCRsaW5lIHwgYXdrICd7cHJpbnQgXFxcJDEgfSdcYAogICAgc2VkIC1pJycgIi9cJHtOQU1FfSAvZCIgL2V0Yy9oYXByb3h5L2hhcHJveHkuY2ZnCmRvbmUKL2V0Yy9pbml0LmQvaGFwcm94eSByZWxvYWQKRU9GCnN1ZG8gbXYgL3RtcC9sZWF2ZS5zaCAvdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9sZWZ0LnNoCmNobW9kICt4IC91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2xlZnQuc2gKCiMgQ29uZmlndXJlIHRoZSBhZ2VudApjYXQgPDxFT0YgPi90bXAvYWdlbnQuY29uZgpkZXNjcmlwdGlvbiAiU2VyZiBhZ2VudCIKc3RhcnQgb24gcnVubGV2ZWwgWzIzNDVdCnN0b3Agb24gcnVubGV2ZWwgWyEyMzQ1XQpleGVjIC91c3IvbG9jYWwvYmluL3NlcmYgYWdlbnQgXFwKICAgIC1ldmVudC1oYW5kbGVyICJtZW1iZXItam9pbj0vdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9qb2luLnNoIiBcXAogICAgLWV2ZW50LWhhbmRsZXIgIm1lbWJlci1sZWF2ZSxtZW1iZXItZmFpbGVkPS91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2xlZnQuc2giIFxcCiAgICAtZXZlbnQtaGFuZGxlciAicXVlcnk6bG9hZD11cHRpbWUiIFxcCiAgICAtdGFnIHJvbGU9JHtTRVJGX1JPTEV9ID4+L3Zhci9sb2cvc2VyZi5sb2cgMj4mMQpFT0YKc3VkbyBtdiAvdG1wL2FnZW50LmNvbmYgL2V0Yy9pbml0L3NlcmYuY29uZgoKIyBTdGFydCB0aGUgYWdlbnQhCnN1ZG8gc3RhcnQgc2VyZgoKIyBJZiB3ZSdyZSB0aGUgd2ViIG5vZGUsIHRoZW4gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlIGpvaW4gcmV0cnkKaWYgWyAieCR7U0VSRl9ST0xFfSIgIT0gInh3ZWIiIF07IHRoZW4KICAgIGV4aXQgMApmaQoKY2F0IDw8RU9G
ID4vdG1wL2pvaW4uY29uZgpkZXNjcmlwdGlvbiAiSm9pbiB0aGUgc2VyZiBjbHVzdGVyIgpzdGFydCBvbiBydW5sZXZlbCBbMjM0NV0Kc3RvcCBvbiBydW5sZXZlbCBbITIzNDVdCnRhc2sKcmVzcGF3bgpzY3JpcHQKICAgIHNsZWVwIDUKICAgIGV4ZWMgL3Vzci9sb2NhbC9iaW4vc2VyZiBqb2luIDEwLjAuMC41CmVuZCBzY3JpcHQKRU9GCnN1ZG8gbXYgL3RtcC9qb2luLmNvbmYgL2V0Yy9pbml0L3NlcmYtam9pbi5jb25mCnN1ZG8gc3RhcnQgc2VyZi1qb2luCgpjYXQgPDxFT0YgPi90bXAvcXVlcnkuY29uZgpkZXNjcmlwdGlvbiAiUXVlcnkgdGhlIHNlcmYgY2x1c3RlciBsb2FkIgpzdGFydCBvbiBydW5sZXZlbCBbMjM0NV0Kc3RvcCBvbiBydW5sZXZlbCBbITIzNDVdCnJlc3Bhd24Kc2NyaXB0CiAgICBlY2hvIGBkYXRlYCBJIGFtICIke0hPU1ROQU1FfTxicj4iID4gL3Zhci93d3cvaW5kZXguaHRtbC4xCiAgICBzZXJmIHF1ZXJ5IC1uby1hY2sgbG9hZCB8IHNlZCAnc3wkfDxicj58JyA+PiAvdmFyL3d3dy9pbmRleC5odG1sLjEKICAgIG12IC92YXIvd3d3L2luZGV4Lmh0bWwuMSAvdmFyL3d3dy9pbmRleC5odG1sCiAgICBzbGVlcCAxMAplbmQgc2NyaXB0CkVPRgpzdWRvIG12IC90bXAvcXVlcnkuY29uZiAvZXRjL2luaXQvc2VyZi1xdWVyeS5jb25mCnN1ZG8gc3RhcnQgc2VyZi1xdWVyeQoKCgoKCg=="
},
"DependsOn": "PublicRouteGlobal"
},
"LoadBalancerIP": {
"Type": "AWS::EC2::EIP",
"Properties": {
"InstanceId": {
"Ref": "LoadBalancer"
},
"Domain": "vpc"
},
"DependsOn": "VPCGateway"
},
"redisasg": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"AvailabilityZones": [{
"Fn::GetAtt": ["PrivateSubnet", "AvailabilityZone"]
}],
"LaunchConfigurationName": {
"Ref": "WebLaunchConfig"
},
"DesiredCapacity": {
"Ref": "redisboxes"
},
"MinSize": {
"Ref": "redisboxes"
},
"MaxSize": {
"Ref": "redisboxes"
},
"VPCZoneIdentifier": [{
"Ref": "PrivateSubnet"
}]
},
"DependsOn": ["NATDevice", "NATIPAddress", "PrivateRouteGlobal"]
},
"RedisboxesConfig": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"ImageId": {
"Fn::FindInMap": ["AWSINSTAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"InstanceType": "m1.small",
"SecurityGroups": [{
"Ref": "InstanceSecurityGroup"
}],
"UserData": "IyEvYmluL3NoCgpzZXQgLWUKCiMgSW5zdGFsbCBIQVByb3h5CnN1ZG8gYXB0LWdldCB1cGRhdGUKc3VkbyBhcHQtZ2V0IGluc3RhbGwgLXkgaGFwcm94eQoKIyBDb25maWd1cmUgaXQgaW4gYSBqYW5rIHdheQpjYXQgPDxFT0YgPi90bXAvaGFwcm94eS5jZmcKZ2xvYmFsCiAgICBkYWVtb24KICAgIG1heGNvbm4gMjU2CgpkZWZhdWx0cwogICAgbW9kZSBodHRwCiAgICB0aW1lb3V0IGNvbm5lY3QgNTAwMG1zCiAgICB0aW1lb3V0IGNsaWVudCA1MDAwMG1zCiAgICB0aW1lb3V0IHNlcnZlciA1MDAwMG1zCgpsaXN0ZW4gc3RhdHMKICAgIGJpbmQgKjo5OTk5CiAgICBtb2RlIGh0dHAKICAgIHN0YXRzIGVuYWJsZQogICAgc3RhdHMgdXJpIC8KICAgIHN0YXRzIHJlZnJlc2ggMnMKCmZyb250ZW5kIHJlZGlzCiAgYmluZCAxMjcuMC4wLjE6NTAwMCBuYW1lIHJlZGlzCiAgZGVmYXVsdF9iYWNrZW5kIHJlZGlzX3NlcnZlcnMKICBtYXhjb25uIDEwMjQKCmJhY2tlbmQgcmVkaXNfc2VydmVycwogIGJhbGFuY2Ugcm91bmRyb2JpbgogICNvcHRpb24gdGNwLWNoZWNrCiAgI3RjcC1jaGVjayBjb25uZWN0CiAgI3RjcC1jaGVjayBzZW5kIFBJTkdcclxuCiAgI3RjcC1jaGVjayBleHBlY3Qgc3RyaW5nICtQT05HCiAgI3RjcC1jaGVjayBzZW5kIFFVSVRcclxuCiAgI3RjcC1jaGVjayBleHBlY3Qgc3RyaW5nICtPSwogICNzZXJ2ZXIgcmVkaXNfNzAwMCBsb2NhbGhvc3Q6NzAwMCBjaGVjayBpbnRlciAxcyB3ZWlnaHQgNzcKICAjc2VydmVyIHJlZGlzXzcwMDEgbG9jYWxob3N0OjcwMDEgY2hlY2sgaW50ZXIgMXMgd2VpZ2h0IDMzCkVPRgpzdWRvIG12IC90bXAvaGFwcm94eS5jZmcgL2V0Yy9oYXByb3h5L2hhcHJveHkuY2ZnCgojIEVuYWJsZSBIQVByb3h5CmNhdCA8PEVPRiA+L3RtcC9oYXByb3h5CkVOQUJMRUQ9MQpFT0YKc3VkbyBtdiAvdG1wL2hhcHJveHkgL2V0Yy9kZWZhdWx0L2hhcHJveHkKCiMgU3RhcnQgaXQKc3VkbyAvZXRjL2luaXQuZC9oYXByb3h5IHN0YXJ0CgpleHBvcnQgU0VSRl9ST0xFPSJyZWRpcyIKCgpjYXQgPDxFT0YgPi90bXAvcmVkaXMuY29uZgpiaW5kIDEyNy4wLjAuMQpwcm90ZWN0ZWQtbW9kZSBubwp0aW1lb3V0IDAKdGNwLWtlZXBhbGl2ZSAzMDAKbG9nbGV2ZWwgbm90aWNlIApwaWRmaWxlIC92YXIvcnVuL3JlZGlzXzYzNzkucGlkCkVPRgoKc3VkbyBtdiAvdG1wL3JlZGlzLmNvbmYgL2V0Yy9yZWRpcy9yZWRpcy5jb25mCgpzZXQgLWUKCnN1ZG8gYXB0LWdldCBpbnN0YWxsIC15IHVuemlwCgpjZCAvdG1wCnVudGlsIHdnZXQgLU8gc2VyZi56aXAgaHR0cHM6Ly9kbC5iaW50cmF5LmNvbS9taXRjaGVsbGgvc2VyZi8wLjYuNF9saW51eF9hbWQ2NC56aXA7IGRvCiAgICBzbGVlcCAxCmRvbmUKdW56aXAgc2VyZi56aXAKc3VkbyBtdiBzZXJmIC91c3IvbG9
},
"DependsOn": "PublicRouteGlobal"
},
"LoadBalancerIP": {
"Type": "AWS::EC2::EIP",
"Properties": {
"InstanceId": {
"Ref": "LoadBalancer"
},
"Domain": "vpc"
},
"DependsOn": "VPCGateway"
},
"redisasg": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"AvailabilityZones": [{
"Fn::GetAtt": ["PrivateSubnet", "AvailabilityZone"]
}],
"LaunchConfigurationName": {
"Ref": "WebLaunchConfig"
},
"DesiredCapacity": {
"Ref": "redisboxes"
},
"MinSize": {
"Ref": "redisboxes"
},
"MaxSize": {
"Ref": "redisboxes"
},
"VPCZoneIdentifier": [{
"Ref": "PrivateSubnet"
}]
},
"DependsOn": ["NATDevice", "NATIPAddress", "PrivateRouteGlobal"]
},
"RedisboxesConfig": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"ImageId": {
"Fn::FindInMap": ["AWSINSTAMI", {
"Ref": "AWS::Region"
}, "AMI"]
},
"InstanceType": "m1.small",
"SecurityGroups": [{
"Ref": "InstanceSecurityGroup"
}],
"UserData": "IyEvYmluL3NoCgpzZXQgLWUKCiMgSW5zdGFsbCBIQVByb3h5CnN1ZG8gYXB0LWdldCB1cGRhdGUKc3VkbyBhcHQtZ2V0IGluc3RhbGwgLXkgaGFwcm94eQoKIyBDb25maWd1cmUgaXQgaW4gYSBqYW5rIHdheQpjYXQgPDxFT0YgPi90bXAvaGFwcm94eS5jZmcKZ2xvYmFsCiAgICBkYWVtb24KICAgIG1heGNvbm4gMjU2CgpkZWZhdWx0cwogICAgbW9kZSBodHRwCiAgICB0aW1lb3V0IGNvbm5lY3QgNTAwMG1zCiAgICB0aW1lb3V0IGNsaWVudCA1MDAwMG1zCiAgICB0aW1lb3V0IHNlcnZlciA1MDAwMG1zCgpsaXN0ZW4gc3RhdHMKICAgIGJpbmQgKjo5OTk5CiAgICBtb2RlIGh0dHAKICAgIHN0YXRzIGVuYWJsZQogICAgc3RhdHMgdXJpIC8KICAgIHN0YXRzIHJlZnJlc2ggMnMKCmZyb250ZW5kIHJlZGlzCiAgYmluZCAxMjcuMC4wLjE6NTAwMCBuYW1lIHJlZGlzCiAgZGVmYXVsdF9iYWNrZW5kIHJlZGlzX3NlcnZlcnMKICBtYXhjb25uIDEwMjQKCmJhY2tlbmQgcmVkaXNfc2VydmVycwogIGJhbGFuY2Ugcm91bmRyb2JpbgogICNvcHRpb24gdGNwLWNoZWNrCiAgI3RjcC1jaGVjayBjb25uZWN0CiAgI3RjcC1jaGVjayBzZW5kIFBJTkdcclxuCiAgI3RjcC1jaGVjayBleHBlY3Qgc3RyaW5nICtQT05HCiAgI3RjcC1jaGVjayBzZW5kIFFVSVRcclxuCiAgI3RjcC1jaGVjayBleHBlY3Qgc3RyaW5nICtPSwogICNzZXJ2ZXIgcmVkaXNfNzAwMCBsb2NhbGhvc3Q6NzAwMCBjaGVjayBpbnRlciAxcyB3ZWlnaHQgNzcKICAjc2VydmVyIHJlZGlzXzcwMDEgbG9jYWxob3N0OjcwMDEgY2hlY2sgaW50ZXIgMXMgd2VpZ2h0IDMzCkVPRgpzdWRvIG12IC90bXAvaGFwcm94eS5jZmcgL2V0Yy9oYXByb3h5L2hhcHJveHkuY2ZnCgojIEVuYWJsZSBIQVByb3h5CmNhdCA8PEVPRiA+L3RtcC9oYXByb3h5CkVOQUJMRUQ9MQpFT0YKc3VkbyBtdiAvdG1wL2hhcHJveHkgL2V0Yy9kZWZhdWx0L2hhcHJveHkKCiMgU3RhcnQgaXQKc3VkbyAvZXRjL2luaXQuZC9oYXByb3h5IHN0YXJ0CgpleHBvcnQgU0VSRl9ST0xFPSJyZWRpcyIKCgpjYXQgPDxFT0YgPi90bXAvcmVkaXMuY29uZgpiaW5kIDEyNy4wLjAuMQpwcm90ZWN0ZWQtbW9kZSBubwp0aW1lb3V0IDAKdGNwLWtlZXBhbGl2ZSAzMDAKbG9nbGV2ZWwgbm90aWNlIApwaWRmaWxlIC92YXIvcnVuL3JlZGlzXzYzNzkucGlkCkVPRgoKc3VkbyBtdiAvdG1wL3JlZGlzLmNvbmYgL2V0Yy9yZWRpcy9yZWRpcy5jb25mCgpzZXQgLWUKCnN1ZG8gYXB0LWdldCBpbnN0YWxsIC15IHVuemlwCgpjZCAvdG1wCnVudGlsIHdnZXQgLU8gc2VyZi56aXAgaHR0cHM6Ly9kbC5iaW50cmF5LmNvbS9taXRjaGVsbGgvc2VyZi8wLjYuNF9saW51eF9hbWQ2NC56aXA7IGRvCiAgICBzbGVlcCAxCmRvbmUKdW56aXAgc2VyZi56aXAKc3VkbyBtdiBzZXJmIC91c3IvbG9
jYWwvYmluL3NlcmYKCiMgVGhlIG1lbWJlciBqb2luIHNjcmlwdCBpcyBpbnZva2VkIHdoZW4gYSBtZW1iZXIgam9pbnMgdGhlIFNlcmYgY2x1c3Rlci4KIyBPdXIgam9pbiBzY3JpcHQgc2ltcGx5IGFkZHMgdGhlIG5vZGUgdG8gdGhlIGxvYWQgYmFsYW5jZXIuCmNhdCA8PEVPRiA+L3RtcC9qb2luLnNoCmlmIFsgInhcJHtTRVJGX1RBR19ST0xFfSIgIT0gInhsYiIgXTsgdGhlbgogICAgZWNobyAiTm90IGFuIGxiLiBJZ25vcmluZyBtZW1iZXIgam9pbi4iCiAgICBleGl0IDAKZmkKd2hpbGUgcmVhZCBsaW5lOyBkbwogICAgUk9MRT1cYGVjaG8gXCRsaW5lIHwgYXdrICd7cHJpbnQgXFxcJDMgfSdcYAogICAgaWYgWyAieFwke1JPTEV9IiAhPSAieHdlYiIgXTsgdGhlbgogICAgICAgIGNvbnRpbnVlCiAgICBmaQogICAgZWNobyBcJGxpbmUgfCBcXAogICAgICAgIGF3ayAneyBwcmludGYgIiAgICBzZXJ2ZXIgJXMgJXMgY2hlY2tcXG4iLCBcJDEsIFwkMiB9JyA+Pi9ldGMvaGFwcm94eS9oYXByb3h5LmNmZwpkb25lCi9ldGMvaW5pdC5kL2hhcHJveHkgcmVsb2FkCkVPRgpzdWRvIG12IC90bXAvam9pbi5zaCAvdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9qb2luLnNoCmNobW9kICt4IC91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2pvaW4uc2gKCiMgVGhlIG1lbWJlciBsZWF2ZSBzY3JpcHQgaXMgaW52b2tlZCB3aGVuIGEgbWVtYmVyIGxlYXZlcyBvciBmYWlscyBvdXQKIyBvZiB0aGUgc2VyZiBjbHVzdGVyLiBPdXIgc2NyaXB0IHJlbW92ZXMgdGhlIG5vZGUgZnJvbSB0aGUgbG9hZCBiYWxhbmNlci4KY2F0IDw8RU9GID4vdG1wL2xlYXZlLnNoCmlmIFsgInhcJHtTRVJGX1RBR19ST0xFfSIgIT0gInhsYiIgXTsgdGhlbgogICAgZWNobyAiTm90IGFuIGxiLiBJZ25vcmluZyBtZW1iZXIgbGVhdmUiCiAgICBleGl0IDAKZmkKd2hpbGUgcmVhZCBsaW5lOyBkbwogICAgTkFNRT1cYGVjaG8gXCRsaW5lIHwgYXdrICd7cHJpbnQgXFxcJDEgfSdcYAogICAgc2VkIC1pJycgIi9cJHtOQU1FfSAvZCIgL2V0Yy9oYXByb3h5L2hhcHJveHkuY2ZnCmRvbmUKL2V0Yy9pbml0LmQvaGFwcm94eSByZWxvYWQKRU9GCnN1ZG8gbXYgL3RtcC9sZWF2ZS5zaCAvdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9sZWZ0LnNoCmNobW9kICt4IC91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2xlZnQuc2gKCiMgQ29uZmlndXJlIHRoZSBhZ2VudApjYXQgPDxFT0YgPi90bXAvYWdlbnQuY29uZgpkZXNjcmlwdGlvbiAiU2VyZiBhZ2VudCIKc3RhcnQgb24gcnVubGV2ZWwgWzIzNDVdCnN0b3Agb24gcnVubGV2ZWwgWyEyMzQ1XQpleGVjIC91c3IvbG9jYWwvYmluL3NlcmYgYWdlbnQgXFwKICAgIC1ldmVudC1oYW5kbGVyICJtZW1iZXItam9pbj0vdXNyL2xvY2FsL2Jpbi9zZXJmX21lbWJlcl9qb2luLnNoIiBcXAogICAgLWV2ZW50LWhhbmRsZXIgIm1lbWJlci1sZWF2ZSxtZW1iZXItZmFpbGVkPS91c3IvbG9jYWwvYmluL3NlcmZfbWVtYmVyX2xlZnQuc2giIFxcCiAgICAtZXZlbnQtaGFuZGxlciAicXVlcnk6bG9hZD11cHRpbWUiIFxcCiAgICAtdGFnIHJvbGU9JHtTRVJGX1JPTEV9ID4+L3Zhci9sb2cvc2VyZi5sb2cgMj4mMQpFT0YKc3VkbyBtdiAvdG1wL2FnZW50LmNvbmYgL2V0Yy9pbml0L3NlcmYuY29uZgoKIyBTdGFydCB0aGUgYWdlbnQhCnN1ZG8gc3RhcnQgc2VyZgoKIyBJZiB3ZSdyZSB0aGUgd2ViIG5vZGUsIHRoZW4gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlIGpvaW4gcmV0cnkKaWYgWyAieCR7U0VSRl9ST0xFfSIgIT0gInh3ZWIiIF07IHRoZW4KICAgIGV4aXQgMApmaQoKY2F0IDw8RU9GID4vdG1wL2pvaW4uY29uZgpkZXNjcmlwdGlvbiAiSm9pbiB0aGUgc2VyZiBjbHVzdGVyIgpzdGFydCBvbiBydW5sZXZlbCBbMjM0NV0Kc3RvcCBvbiBydW5sZXZlbCBbITIzNDVdCnRhc2sKcmVzcGF3bgpzY3JpcHQKICAgIHNsZWVwIDUKICAgIGV4ZWMgL3Vzci9sb2NhbC9iaW4vc2VyZiBqb2luIDEwLjAuMC41CmVuZCBzY3JpcHQKRU9GCnN1ZG8gbXYgL3RtcC9qb2luLmNvbmYgL2V0Yy9pbml0L3NlcmYtam9pbi5jb25mCnN1ZG8gc3RhcnQgc2VyZi1qb2luCgpjYXQgPDxFT0YgPi90bXAvcXVlcnkuY29uZgpkZXNjcmlwdGlvbiAiUXVlcnkgdGhlIHNlcmYgY2x1c3RlciBsb2FkIgpzdGFydCBvbiBydW5sZXZlbCBbMjM0NV0Kc3RvcCBvbiBydW5sZXZlbCBbITIzNDVdCnJlc3Bhd24Kc2NyaXB0CiAgICBlY2hvIGBkYXRlYCBJIGFtICIke0hPU1ROQU1FfTxicj4iID4gL3Zhci93d3cvaW5kZXguaHRtbC4xCiAgICBzZXJmIHF1ZXJ5IC1uby1hY2sgbG9hZCB8IHNlZCAnc3wkfDxicj58JyA+PiAvdmFyL3d3dy9pbmRleC5odG1sLjEKICAgIG12IC92YXIvd3d3L2luZGV4Lmh0bWwuMSAvdmFyL3d3dy9pbmRleC5odG1sCiAgICBzbGVlcCAxMAplbmQgc2NyaXB0CkVPRgpzdWRvIG12IC90bXAvcXVlcnkuY29uZiAvZXRjL2luaXQvc2VyZi1xdWVyeS5jb25mCnN1ZG8gc3RhcnQgc2VyZi1xdWVyeQo="
}
},
"InstanceSecurityGroup": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Serf demo security group",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [{
"IpProtocol": "icmp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "6379",
"ToPort": "6379",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "7946",
"ToPort": "7946",
"CidrIp": "0.0.0.0/0"
}
},
"InstanceSecurityGroup": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Serf demo security group",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [{
"IpProtocol": "icmp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "6379",
"ToPort": "6379",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "7946",
"ToPort": "7946",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "7373",
"ToPort": "7373",
"CidrIp": "0.0.0.0/0"
}]
}
},
"InstanceSecurityGroupec2": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "ec2 jump security grp",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [{
"IpProtocol": "icmp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
}],
"SecurityGroupEgress": {
"IpProtocol": "tcp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}
}
},
"ec2Server": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId": "ami-123456",
"InstanceType": {
"Ref": "InstanceType"
},
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroupec2"
}],
"SubnetId": {
"Ref": "PublicSubnet"
},
},
}
"InstanceSecurityGroupSelfRule": {
"Type": "AWS::EC2::SecurityGroupIngress",
"Properties": {
"GroupId": {
"Ref": "InstanceSecurityGroup"
},
"IpProtocol": "-1",
"FromPort": "0",
"ToPort": "65535",
"SourceSecurityGroupId": {
"Ref": "InstanceSecurityGroup"
}
}
}
}
}
lbuserdata.sh
#!/bin/sh
set -e
# Install HAProxy
sudo apt-get update
sudo apt-get install -y haproxy
# Configure it in a jank way
cat <<EOF >/tmp/haproxy.cfg
global
daemon
maxconn 256
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen stats
bind *:9999
mode http
stats enable
stats uri /
stats refresh 2s
#listen http-in
# bind *:80
# balance roundrobin
# option http-server-close
frontend redis
bind 127.0.0.1:5000 name redis
default_backend redis_servers
maxconn 1024
backend redis_servers
balance roundrobin
#option tcp-check
#tcp-check connect
#tcp-check send PING\r\n
#tcp-check expect string +PONG
#tcp-check send QUIT\r\n
#tcp-check expect string +OK
#server redis_7000 localhost:7000 check inter 1s weight 77
#server redis_7001 localhost:7001 check inter 1s weight 33
EOF
sudo mv /tmp/haproxy.cfg /etc/haproxy/haproxy.cfg
# Enable HAProxy
cat <<EOF >/tmp/haproxy
ENABLED=1
EOF
sudo mv /tmp/haproxy /etc/default/haproxy
# Start it
sudo /etc/init.d/haproxy start
export SERF_ROLE="lb"
set -e
sudo apt-get install -y unzip
cd /tmp
until wget -O serf.zip https://dl.bintray.com/mitchellh/serf/0.6.4_linux_amd64.zip; do
sleep 1
done
unzip serf.zip
sudo mv serf /usr/local/bin/serf
# The member join script is invoked when a member joins the Serf cluster.
# Our join script simply adds the node to the load balancer.
cat <<EOF >/tmp/join.sh
if [ "x\${SERF_TAG_ROLE}" != "xlb" ]; then
echo "Not an lb. Ignoring member join."
exit 0
fi
while read line; do
ROLE=\`echo \$line | awk '{print \\\$3 }'\`
if [ "x\${ROLE}" != "xweb" ]; then
continue
fi
echo \$line | \\
awk '{ printf " server %s %s check\\n", \$1, \$2 }' >>/etc/haproxy/haproxy.cfg
done
/etc/init.d/haproxy reload
EOF
sudo mv /tmp/join.sh /usr/local/bin/serf_member_join.sh
chmod +x /usr/local/bin/serf_member_join.sh
# The member leave script is invoked when a member leaves or fails out
# of the serf cluster. Our script removes the node from the load balancer.
cat <<EOF >/tmp/leav
"IpProtocol": "tcp",
"FromPort": "7373",
"ToPort": "7373",
"CidrIp": "0.0.0.0/0"
}]
}
},
"InstanceSecurityGroupec2": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "ec2 jump security grp",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [{
"IpProtocol": "icmp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}, {
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
}],
"SecurityGroupEgress": {
"IpProtocol": "tcp",
"FromPort": "-1",
"ToPort": "-1",
"CidrIp": "0.0.0.0/0"
}
}
},
"ec2Server": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId": "ami-123456",
"InstanceType": {
"Ref": "InstanceType"
},
"SecurityGroupIds": [{
"Ref": "InstanceSecurityGroupec2"
}],
"SubnetId": {
"Ref": "PublicSubnet"
},
},
}
"InstanceSecurityGroupSelfRule": {
"Type": "AWS::EC2::SecurityGroupIngress",
"Properties": {
"GroupId": {
"Ref": "InstanceSecurityGroup"
},
"IpProtocol": "-1",
"FromPort": "0",
"ToPort": "65535",
"SourceSecurityGroupId": {
"Ref": "InstanceSecurityGroup"
}
}
}
}
}
lbuserdata.sh
#!/bin/sh
set -e
# Install HAProxy
sudo apt-get update
sudo apt-get install -y haproxy
# Configure it in a jank way
cat <<EOF >/tmp/haproxy.cfg
global
daemon
maxconn 256
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen stats
bind *:9999
mode http
stats enable
stats uri /
stats refresh 2s
#listen http-in
# bind *:80
# balance roundrobin
# option http-server-close
frontend redis
bind 127.0.0.1:5000 name redis
default_backend redis_servers
maxconn 1024
backend redis_servers
balance roundrobin
#option tcp-check
#tcp-check connect
#tcp-check send PING\r\n
#tcp-check expect string +PONG
#tcp-check send QUIT\r\n
#tcp-check expect string +OK
#server redis_7000 localhost:7000 check inter 1s weight 77
#server redis_7001 localhost:7001 check inter 1s weight 33
EOF
sudo mv /tmp/haproxy.cfg /etc/haproxy/haproxy.cfg
# Enable HAProxy
cat <<EOF >/tmp/haproxy
ENABLED=1
EOF
sudo mv /tmp/haproxy /etc/default/haproxy
# Start it
sudo /etc/init.d/haproxy start
export SERF_ROLE="lb"
set -e
sudo apt-get install -y unzip
cd /tmp
until wget -O serf.zip https://dl.bintray.com/mitchellh/serf/0.6.4_linux_amd64.zip; do
sleep 1
done
unzip serf.zip
sudo mv serf /usr/local/bin/serf
# The member join script is invoked when a member joins the Serf cluster.
# Our join script simply adds the node to the load balancer.
cat <<EOF >/tmp/join.sh
if [ "x\${SERF_TAG_ROLE}" != "xlb" ]; then
echo "Not an lb. Ignoring member join."
exit 0
fi
while read line; do
ROLE=\`echo \$line | awk '{print \\\$3 }'\`
if [ "x\${ROLE}" != "xweb" ]; then
continue
fi
echo \$line | \\
awk '{ printf " server %s %s check\\n", \$1, \$2 }' >>/etc/haproxy/haproxy.cfg
done
/etc/init.d/haproxy reload
EOF
sudo mv /tmp/join.sh /usr/local/bin/serf_member_join.sh
chmod +x /usr/local/bin/serf_member_join.sh
# The member leave script is invoked when a member leaves or fails out
# of the serf cluster. Our script removes the node from the load balancer.
cat <<EOF >/tmp/leav