Items tagged with: containers
Did you know Linux Journal has several dozen ebooks you can download for free? No login required. https://www.linuxjournal.com/books
#Linux #opensource #FOSS #sysadmin #programming #security #CloudComputing #containers #devops #drupal #Docker #Kubernetes #SQL ...and on and on
Linux LXD Containers '#2' Images and Snaps
How to use and interact with #images and #snapshots in a Linux LXD Container on #Ubuntu.
#LXD #Containers are a #Hypervisor that allows you to manage #LXC containers. LXC containers are very #lightweight fast #secure #Linux #virtual machines.
#VirtualOS #technology #Ubuntu #LXD #LXC #container #secure
Linux LXD Containers '#1' Getting Started
How to install and configure Linux an LXD Container on #Ubuntu.
#LXD #Containers are a #Hypervisor that allows you to manage #LXC containers. LXC containers are very lightweight fast #secure #Linux #virtual machines.
Linux LXD Containers #1 Getting Started
How to install and configure Linux an LXD Container on Ubuntu.
LXD Containers are a Hypervisor that allows you to manage LXC containers. LXC containers are very lightweight fast secure Linux virtual machines.
#Linux #Ubuntu #containers #LXD #LXC #virtualOS #secure #peertube #technology #hypervisor
What is a microservice? Should you be using microservices? How are microservices related to containers and Kubernetes? If these things keep coming up in your day-to-day and you need an overview in 10…
HN Discussion: https://news.ycombinator.com/item?id=19321070
Posted by old-gregg (karma: 8014)
Post stats: Points: 135 - Comments: 32 - 2019-03-06T18:08:47Z
#HackerNews #and #containers #kubernetes #microservices #minutes #ten
What is a microservice? Should you be using microservices? How are microservices related to containers and Kubernetes? If these things keep coming up in your day-to-day and you need an overview in 10 minutes, this blog post is for you.
Fundamentally, a microservice is just a computer program which runs on a server or a virtual computing instance and responds to network requests.
How is this different from a typical Rails/Django/Node.js application? It is not different at all. In fact, you may discover that you already have a dozen of microservices deployed at your organization. There are not any new magical technologies that qualify your application to be called a microservice. A microservice is not defined by how it is built but by how it fits into the broader system or solution.
So what makes a service a microservice? Generally, microservices have a more narrow scope and focus on doing smaller tasks well. Let’s explore further by looking at an example.
Example: Amazon Product Listing
Let’s examine the system which serves you this product page on Amazon. It contains several blocks of information, probably retrieved from different databases:
* The product description, which includes the price, title, photo, etc. * Recommended items, i.e. similar books other people have bought. * Sponsored listings that are related to this item. * Information about the author of the book. * Customer reviews. * Your own browsing history of other items on the Amazon store.
If you were to quickly write the code which serves this listing, the simple approach would look something like this:
When a user’s request comes from a browser, it will be served by a web application (a Linux or Windows process). Usually, the application code fragment which gets invoked is called a request handler. The logic inside of the handler will sequentially make several calls to databases, fetch the required information needed to render a page and stitch it together and render a web page to be returned to the user. Simple, right? In fact, many of Ruby on Rails books feature tutorials and examples that look like this. So, why complicate things, you may ask?
Imagine what happens as the application grows and more and more engineers become involved. The recommendation engine alone in the example above is maintained by a small army of programmers and data scientists. There are dozens of different teams who are responsible for some component of rendering that page. Each of those teams usually wants the freedom to:
1. Change their database schema.
2. Release their code to production quickly and often.
3. Use development tools like programming languages or data stores of their choice.
4. Make their own trade-offs between computing resources and developer productivity.
5. Have a preference for maintenance/monitoring of their functionality.
As you can imagine, having the teams agree on everything to ship newer versions of the web store application will become more difficult over time.
The solution is to split up the components into smaller, separate services (aka, microservices).
The other microservices are now separated out and each development team working on their microservice can:
* Deploy their service as frequently as they wish without disrupting other teams. * Scale their service the way they see fit. For example, use AWS instance types of their choice or perhaps run on specialized hardware. * Have their own monitoring, backups and disaster recovery that are specific to their service.
What is the difference between microservices and containers?
A container is just a method of packaging, deploying and running a Linux program/process. You could have one giant monolithic application as a container and you could have a swarm of microservices that do not user containers, at all.
A container is a useful resource allocation and sharing technology. It’s something devops people get excited about. A microservice is a software design pattern. It’s something developers get excited about.
Containers and microservices are both useful but not dependent on each other.
When to use Microservices?
The idea behind microservices is not new. For decades, software architects have been at work trying to decouple monolithic applications into reusable components. The benefits of microservices are numerous and include:
* easier automated testing; * rapid and flexible deployment models; and * higher overall resiliency.
The drawbacks of microservices include:
* the need for more careful planning; * higher R&D investment up front; and * the temptation of over-engineering.
If an application and development team is small enough and the workload isn’t challenging, there is usually no need to throw additional engineering resources into solving problems you do not have yet and use microservices. However, if you are starting to see the benefits of microservices outweigh the disadvantages, here are some specific design considerations:
1. Separation of computing and storage. As your needs for CPU power and storage grow, these resources have very different scaling costs and characteristics. Not having to rely on local storage from the beginning will allow you to adapt to future workloads with relative ease. This applies to both simple storage forms like file systems and more complex solutions such as databases.
2. Asynchronous processing. The traditional approach of gradually building applications by adding more and more subroutines or objects who call each other stops working as workloads grow and the application itself must be stretched across multiple machines or even data centers. Re-architecting an application around the event-driven model will be required. This means sending an event (and not waiting for a result) instead of calling a function and synchronously waiting for a result.
3. Embrace the message bus. This is a direct consequence of having to implement an asynchronous processing model. As your monolithic application gets broken into event handlers and event emitters, the need for a robust, performant and flexible message bus is required. There are numerous options and the choice depends on application scale and complexity. For a simple use case, something like Redis will do. If you need your application to be truly cloud-native and scale itself up and down, you may need the ability to process events from multiple event sources: from streaming pipelines like Kafka to infrastructure and even monitoring events.
4. API versioning. As your microservices will be using each other’s APIs to communicate with each other via a bus, designing a schema for maintaining backward compatibility will be critical. Simply by deploying the latest version of one microservice, a developer should not be demanding everyone else to upgrade their code. This will be a step backward towards the monolith approach, albeit separated across application domains. Development teams must agree upon a reasonable compromise between supporting old APIs forever and keeping the higher velocity of development. This also means that API design becomes an important skill. Frequent breaking API changes is one of the reasons teams fail to be productive in developing complex microservices.
5. Rethink your security. Many developers do not realize this but migrating to microservices creates an opportunity for a much better security model. As every microservice is a specialized process, it is a good idea to only allow it to access resources it needs. This way a vulnerability in just one microservice will not expose the rest of your system to an attacker. This is in contrast with a large monolith which tends to run with elevated privileges (a superset of what everyone needs) and there is limited opportunity to restrict the impact of a breach.
What does Kubernetes have to do with microservices?
Kubernetes is too complex to describe in detail here, but it deserves an overview since many people bring it up in conversations about microservices.
Strictly speaking, the primary benefit of Kubernetes (aka, K8s) is to increase infrastructure utilization through the efficient sharing of computing resources across multiple processes. Kubernetes is the master of dynamically allocating computing resources to fill the demand. This allows organizations to avoid paying for computing resources they are not using. However, there are side benefits of K8s that make the transition to microservices much easier.
As you break down your monolithic application into separate, loosely-coupled microservices, your teams will gain more autonomy and freedom. However, they still have to closely cooperate when interacting with the infrastructure the microservices must run on.
You will have to solve problems like:
* predicting how much computing resources each service will need; * how these requirements change under load; * how to carve out infrastructure partitions and divide them between microservices; and * enforce resource restrictions.
Kubernetes solves these problems quite elegantly and provides a common framework to describe, inspect and reason about infrastructure resource sharing and utilization. That’s why adopting Kubernetes as part of your microservice re-architecture is a good idea.
Kubernetes, however, is a complex technology to learn and it’s even harder to manage. You should take advantage of a hosted Kubernetes service provided by your cloud provider if you can. However, this is not always viable for companies who need to run their own Kubernetes clusters across multiple cloud providers and enterprise data centers.
For such use cases, we recommend trying out Gravity, the open source Kubernetes packaging solution, which removes the need for Kubernetes administration. Gravity works by creating Kubernetes clusters from a single image file or “Kubernetes appliances” and can be downloaded, moved, created and destroyed by the hundreds, making it possible to treat Kubernetes clusters like cattle, not pets.
1. Microservices are not new. It’s an old software design pattern which has been growing in popularity due to the growing scale of Internet companies.
2. Small projects should not shy from the monolithic design. It offers higher productivity for smaller teams.
3. Kubernetes is a great platform for complex applications comprised of multiple microservices.
4. Kubernetes is also a complex system and hard to run. Consider using hosted Kubernetes if you can.
5. If you must run your own K8s clusters or if you need to publish your K8s applications as downloadable appliances, consider the open source solution, Gravity.
HackerNewsBot debug: Calculated post rank: 100 - Loop: 191 - Rank min: 100 - Author rank: 72
A performance comparison between three different methods of deploying an API on AWS
Article word count: 1882
HN Discussion: https://news.ycombinator.com/item?id=19233466
Posted by abd12 (karma: 700)
Post stats: Points: 108 - Comments: 50 - 2019-02-23T14:38:32Z
#HackerNews #api #aws #comparison #containers #performance #serverless
In my last post, I showed how to connect AWS API Gateway directly to SNS using a service integration.
A few people asked me about the performance implications of this architecture.
Is it significantly faster than using a Lambda-based approach?
How does it compare to EC2 or ECS?
My answer: I don’t know! But I know how to find out (sort of).
In this post, we do a performance bake-off of three ways to deploy the same HTTP endpoint in AWS:
* Using an API Gateway service proxy * With the new hotness, AWS Lambda * With the old hotness, Docker containers on AWS Fargate
We’ll deploy our three services and throw 15,000 requests at each of them. Who will win?
If you’re impatient, skip here to see full results
Table of Contents:
Before we review the results, let’s set up the problem.
I wanted to keep our example as simple as possible so that the comparison is limited to the architecture itself rather than the application code. Further, I wanted an example that would work with the API Gateway service proxy so we could use it as a comparison as well.
I decided to set up a simple endpoint that receives an HTTP POST request and forwards the request payload into an AWS SNS topic.
Let’s take a look at the architecture and deployment methods for each of our three approaches.
Go Serverless with AWS Lambda
The first approach is to use AWS API Gateway and AWS Lambda. Our architecture will look like this:
SNS Publish with Lambda
A user will make an HTTP POST request to our endpoint, which will be handled by API Gateway. API Gateway will forward the request to our AWS Lambda function for processing. The Lambda function will send our request payload to the SNS topic before returning a response.
If you want to deploy this example, the code is available here. I use the Serverless Framework for deploying the architecture because I think it’s the easiest way to do it.*
*Full disclosure: I work for Serverless, Inc., creators of the Serverless Framework. Want to come work with me on awesome stuff? We’re hiring engineers. Please reach out if you have any interest.
Skipping the middleman with API Gateway service proxy
The second approach is similar to the first, but we remove Lambda from the equation. We use an API Gateway service proxy integration to publish directly to our SNS topic from API Gateway:
APIG Service Proxy
Before doing any testing, my hunch is that this will be faster than the previous method since we’re cutting out a network hop in the middle. Check below for full results. Note that API Gateway service proxies won’t work for all parts of your infrastructure, even if the performance is faster.
If you want additional details on how, when, and why to use this, check out my earlier post on using an API Gateway service proxy integration. It does a step-by-step walkthrough of setting up your first service proxy.
To deploy this example, there is a CloudFormation template here. This will let you quickly spin up the stack for testing.
Containerizing your workload with Docker and AWS Fargate
The final approach is to run our compute in Docker containers. There are a few different approaches for doing this on AWS, but I chose to use AWS Fargate.
The architecture will look as follows:
Fargate to SNS
Users will make HTTP POST requests to an HTTP endpoint, which will be handled by an Application Load Balancer (ALB). This ALB will forward requests to our Fargate container instances. The application on our Fargate container instances will forward the request payload to SNS.
With Fargate, you can run tasks or services. A task is a one-off container that will run until it dies or finishes execution. A service is a defined set of a certain number of instances of a task. Fargate will ensure the correct number of instances of your service are running.
We’ll use a service so that we can run a sufficient number of instances. Further, you can easily set up a load balancer for managing HTTP traffic across your service instances.
You can find code and instructions for deploying this architecture to Fargate here. I use the incredible fargate CLI tool, which makes it dead simple to go from Dockerfile to running container.
Now that we know our architecture, let’s jump into the bakeoff!
After I deployed all three of the architectures, I wanted to do testing in two phases.
First, I ran a small sample of 2000 requests to check the performance of new deploys. This was running at around 40 requests per second.
Then, I ran a larger test of 15000 requests to see how each architecture performed when they are warmed up. For this larger test, I was sending around 100 requests per second.
Let’s check the results in order.
When I ran my initial Fargate warmup, I got the following results:
screen shot 2019-02-19 at 7 33 08 pm
Around 10% of my requests were failing altogether!
When I dug in, it looked like I was overwhelming my container instances, causing them to die.
I’m not a Docker or Flask performance expert, and that’s not the goal of this exercise. To remedy this, I decided to bump the specs on my deployments.
The general goal for this bakeoff is to get a best-case outcome for each of these architectures, rather than an apples-to-apples comparison of cost vs performance.
For Fargate, this meant deploying 50 instances of my container with pretty beefy settings — 8 GB of memory and 4 full CPU units per container instance.
For the Lambda service, I set memory to the maximum of 3GB.
For APIG service proxy, there are no knobs to tune. 🎉
With that out of the way, let’s check the initial results.
Initial warmup results
For the first 2000 requests to each type of endpoint, the performance results are as follows:
api performance results -- warmup
Note: Chart using a log scale
The raw data for the results are:
Endpoint type # requests 50% 66% 75% 80% 90% 95% 98% 99% 100%
APIG Service Proxy 2051 80 90 110 120 150 190 220 250 520
AWS Lambda 2084 94 100 110 120 150 180 210 290 5100
Fargate 2047 68 73 76 80 110 110 130 140 550
Takeaways from the warmup test
1. Fargate was consistently the fastest across all percentiles.
2. AWS Lambda had the longest tail on all of them. This is due to the cold start problem.
3. API Gateway service proxy outperformed AWS Lambda at the median, but performance in the upper-middle of the range (75% - 99%) was pretty similar between the two.
Now that we’ve done our warmup test, let’s check out the results from the full performance test.
Full performance test results
For the main part of the performance test, I ran 15,000 requests at each of the three architectures. I planned to use 500 ‘users’ in Locust to accomplish this, though, as noted below, I had to make some modifications for Fargate.
First, let’s check the results:
api performance results -- full test
Note: Chart using a log scale
The raw data for the results are:
Endpoint type # requests 50% 66% 75% 80% 90% 95% 98% 99% 100%
APIG Service Proxy 15185 73 79 84 90 130 180 250 290 670
AWS Lambda 15249 86 92 98 110 140 160 180 220 920
Fargate 15057 69 72 75 77 91 110 130 170 800
Takeaways from the full performance test
1. Fargate was still the fastest across the board, though the gap narrowed. API Gateway service proxy was nearly as fast as Fargate at the median, and AWS Lambda wasn’t far behind.
2. The real differences show up between the 80th and 99th percentile. Fargate had a lot more consistent performance as it moved up the percentiles. The 98th percentile request for Fargate is less than double the median (130ms vs 69ms, respectively). In contrast, the 98th percentile for API Gateway service proxy was more than triple the median (250ms vs 73ms, respectively).
3. AWS Lambda outperformed the API Gateway service proxy at some higher percentiles. Between the 95th and 99th percentiles, AWS Lambda was actually faster than the API Gateway service proxy. This was surprising to me.
I mentioned above that I wanted to use 500 Locust ‘users’ when testing the application. Both AWS Lambda and API Gateway service proxy handled 15000+ requests without a single error.
With Fargate, I consistently had failed requests:
screen shot 2019-02-20 at 6 25 16 am
I finally throttled it down to 200 Locust users when testing for Fargate, which got my error rate down to around 3% of overall requests. Still, this was infinitely higher than the error with AWS Lambda.
I’m not saying you can’t deploy a Fargate service without tolerating a certain percentage of failures. Rather, performance tuning Docker containers was more time than I wanted to spend on a quick performance test.
UPDATED NOTES ON FARGATE ERRORS
I’ve gotten some pushback saying that the test is worthless due to the Fargate errors, or that I was way over-provisioned on Fargate.
A few notes on that:
First, Nathan Peck, an awesome and helpful container advocate at AWS, reached out to say the failures were likely around some system settings like the ‘nofile’ ulimit.
That sounds pretty reasonable to me, but I haven’t taken the time to test it out. I don’t have huge interest in digging deep into container performance tuning for this. If that’s something you’re into, let me know and I’ll link to your results if they’re interesting!
The key points on Fargate are:
1. You can get much lower failure rates than I got. You’ll just need to tune it.
2. I didn’t use 50 instances with a ton of CPU and memory because I thought Fargate needed it. I used it because I didn’t want to think about resource exhaustion at all (even though I did end up hitting the open file limits). I was going for a best-case scenario — if the load balancer, container, and SNS are all humming, what kind of latency can we get?
3. I don’t think this invalidates the general results of what a basic ‘optimistic-case’ could look like with Fargate within these general constraints (multiple instances + Python + calling SNS).
If you’re making a million dollar decision on this, you should run your own tests.
If you want a quick, fun read, these results should be directionally correct.
This was a fun and enlightening experience for me, and I hope it was helpful for you. There’s not a clear right answer on which architecture you should use based on these performance results.
Here’s how I think about it:
* Do you need high performance? Using dedicated instances with Fargate (or ECS/EKS/EC2) is your best best. This will require more setup and infrastructure management, but that may be necessary for your use case. * Is your business logic limited? If so, use API Gateway service proxy. API Gateway service proxy is a performant, low-maintenance way to stand up endpoints and forward data to another AWS service. * In the vast number of other situations, use AWS Lambda. Lambda is dead-simple to deploy (if you’re using a deployment tool). It’s reliable and scalable. You don’t have to worry about tuning a bunch of knobs to get solid performance. And it’s code, so you can do anything you want. I use it for almost everything.
HackerNewsBot debug: Calculated post rank: 88 - Loop: 425 - Rank min: 80 - Author rank: 127
Best way to run Wine on 64-bit Debian
I am trying to figure out how running Wine in a very cool way, I mean modern and isolated, there are several way to achieve it but I would like to see your opinion!
#debian #linux #winehq #opensource #containers #docker #systemd #systemadmin #floss #foss #freesoftware #sysadmin