|
Quick Answers of course !
Looking forward to your question, I just happened to do NuGet packaging on our TeamCity server 
|
|
|
|
|
I put it in Visual Studio forum because I thought it might be more of a conversation than a question. Plus, I hate the comment part of Q/A - the text is almost invisible to me and too small to boot.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
If you're asking because you want to know where "those responsible" live and want to show up at their door...please, just ask right here. I'd like to know the answer to that myself...
|
|
|
|
|
And if so, why?
I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
|
|
|
|
|
Everything you didn't write is hype.
|
|
|
|
|
I have no clue what all of these words mean.
"Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management."
I'd rather be phishing!
|
|
|
|
|
Quote: container-orchestration
They used to make drums out of old steel barrels. If they used a 60 ft. shipping container they would have enough for an entire orchestra. That's what these words must mean. I don't know about the rest of it.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Maximilien wrote: "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management."
The second half of that sentence sounds to me like what ARM templates are intended do on Azure.
The first half is mostly gibberish to me.
|
|
|
|
|
Maximilien wrote: I have no clue what all of these words mean.
Exactly. It sounds like an open air symphony where the beer and wine are provided free by waiters and depending on how much you drink, you get a free ride back home.
|
|
|
|
|
I use Kubernetes (and Docker obviously). Let's start with why I use Docker. With Docker, I build a series of images that can be applied to a container. What this simply means is that I have a number of steps described that get a system into a known and predictable state that can be applied from simple commands. In practice this means that I can say that I have a series of steps that describe how to build up (as an example), a Red Hat server running SQL Server. Now, that's great if you only want one of these running up, but what happens when you build a system that has tens or hundreds of these? That's where Kubernetes comes in. It makes managing these "on-demand" containers an absolute breeze.
|
|
|
|
|
Pete O'Hanlon wrote: It makes managing these "on-demand" containers an absolute breeze.
Ah. OK, that starts to make sense. So it figures out the load requirements and spins up additional containers as necessary, and spins them down when the load goes down?
|
|
|
|
|
Kubernetes is particularly useful at distributing work intelligently when modes are added/removed.
|
|
|
|
|
I've used it - only for personal projects and not here at CodeProject so far, but I think I can write a bit about its usefulness.
To start, there are two scenarios to consider:
1. You have to set up, maintain, and manage a Kubernetes cluster yourself. This can be a real pain, unless you have a Linux sysadmin handy, or enjoy being one yourself.
2. You're going to use a cloud Kubernetes service. Azure, AWS, and Google Cloud (along with lots of others) offer this, and it's the happy path for developers.
I'll be discussing scenario 2 because it's the situation most developers find themselves in.
I've found that Kubernetes is one of those things where you don't need it until you do, and when you do, it's really nice to have it. To jump on the Kubernetes bandwagon, you first have to jump on the container bandwagon. But it's a fairly easy bandwagon to jump on, conceptually. It's a nice way of ensuring that your app is running in very close to the same environment in production as it was while in development.
This cuts down on those good old bugs where everything works on the developer's machine, then goes to hell in production. It also makes deployment nice and easy. You push your changes to your app's Git repository, then your CI system builds your application and if all the tests pass, bundles it up into a container and pushes that container to a container registry like Docker Hub or Azure Container Registry. Or you can do things the old fashioned way and build the app on your own machine, run the tests (you do have tests, right?), and then manually build the container and push it to a registry.
Now, it's time to deploy. You sign in to your production server and run a command that basically says "hey Docker, pull the latest version of my app from the registry" and poof! Magic! The latest version of your app is on the production server. At this point, you'll usually need to ask Docker to restart the container too, to ensure that the newest version is running.
That took a couple of steps, but it's still pretty nice. No XCOPYing files to servers. No copy-and-pasting via remote desktop. No weird errors caused by forgetting to install a dependency your app needs. Since your app's container is self-contained and has all of the dependencies included, it just works reliably every time.
This is all well and good, and it's often a step up from the ad-hoc prayer and duct tape-based deployment processes that a shocking number of dev teams are using.
But it all falls apart when your application starts getting big enough that you want to split it up into multiple services and/or run multiple instances and load balance between them. Then, instead of just signing in to a single production server and pulling down a new container version, you have to sign in to many machines and pull down one or more containers. Which is a pain.
This is where container orchestration applications like Kubernetes come in handy. Envision the following scenario:
* You have a front-end web application that gets a lot of traffic and you need to run 10 instances of the app and load balance between them
* You have a few back-end services that the front-end web app talks to. You also need multiple instances of these, but not as many instances as your web server
* Two of your back-end services really, really need to always be deployed together so they're always running on the same machine because they need a shared filesystem so one service can process the output of another
So trying to do all of this manually is possible, but trying to do all of this manually becomes a big pain very quickly. When you need to update your services, there's a lot of drudge work involved. And I know that there are plenty of non-Kubernetes ways to automate complex deployments. I've just found Kubernetes to be fairly nice to work with.
Given the scenario above, the process on Azure Kubernetes looks like the following:
* Tell AKS to create a new Kubernetes cluster
* Tell AKS to add some worker nodes to your new cluster. These nodes are just VMs to which AKS can deploy container
* Set up a Kubernetes config file that tells it something like:
* Here's my web service. Its container name is xyz. It needs at least 512MB of RAM, and don't let it use more than 2GB of RAM. You should run at least one instance of it, and at most 10 instances. Scale up only if average CPU use if > 50%.
* Add similar config sections for each of your backend services with RAM and/or CPU minimums and maximums that are appropriate to each service
* Specify that backend service C and backend service D need to always be deployed together. Kubernetes calls this a pod. Specify that the pod should always have a shared volume of a certain size attached.
So, given the above, Kubernetes takes your config file, looks at all of the nodes it has available, and decides where to deploy everything based on the requirements and constraints you've provided. There's lots of flexibility. You don't have to provide a maximum number of instances, for example. You can let Kubernetes keep scaling a service up as long as it has space available on the nodes in the cluster. And if your app grows or experiences a spike in traffic and suddenly needs more horsepower to keep up, no problem. Add more nodes to your cluster and Kubernetes will figure out where and when to spin up new instances of whatever is needed.
Hm, I think I'd better end this here. I came in intending to do a brief overview, and this message is starting to approach article length. 
I've mostly just scratched the surface. I've skipped lots of details, but hopefully, I've given a decent enough look at why Kubernetes is something you might care about. It's not the right solution for every problem. If your app will work using just Azure functions, or Azure App Service, or Google App Engine, those are all easier to use. But as we all know, the real world is full of tricky problems that need complex solutions, and in those cases, Kubernetes might just be exactly what you need.
|
|
|
|
|
It appears you have the basis for an article right there and very little more is needed.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
> and if all the tests pass
Ryan Peden wrote: and this message is starting to approach article length.
I was just thinking that as I rounded the final couple bends in your post. Awesome writeup!!! Thank you!
|
|
|
|
|
Quote: Hm, I think I'd better end this here. I came in intending to do a brief overview, and this message is starting to approach article length.
I've mostly just scratched the surface. I've skipped lots of details
I've never had enough interest in Kubernetes to read much about it, but I did leave a browser tab opened until I had time to come back to it and read your write-up just now.
This is absolutely an article I would read, if you'd care to add those details you've skipped. You have a writing style that has kept me interested throughout, and I'd be interested in knowing what else you think might be important in an overview.
|
|
|
|
|
|
Is a trail blazer formal jungle-wear?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That should sound pithier than it does.
|
|
|
|
|
I hades to say this but speaking of hell-mutts, wouldn't bringing up Cerberus be part of yesterday's mythological ToD thread?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You have, however fired up my imagination for a bush-league comment:
A trail blazer is a person who while walking through forest paths burns their pharts behind them - everyone knows that.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Only if it comes with a fancy machete.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
So that's what the cummerbund is for; to keep your fancy machete in.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Is someone who blazes trails an arson?
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
Recently [^] there was a post as to what causes agile to fail. Primarily, it blamed corporate culture. Interesting, to me, because it's real and true global philosophy is to give the appearance of progress and thus give a hierarchy of management something to report. Charts, videos, and (especially!) powerpoint with circles and arrows and a paragraph on the back of each . . .
Has it ever occurred to its infeccionados that agile fails because it a failure? I propose the following:
Agile is a failure because it was developed by agile thinking: get something out quick and make it work later.
Except they forgot that last bit.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
