Vagrant is for setting up test environments right? Ansible/Chef etc. seem good for servers you own, but what about cloud? Docker... great for standardizing app, so why use Ansible/Chef? Kubernentes.. good for deploying to multiple environments and scaling
Just a personal note: the way you formulate these things makes me assume that you are diving freshly into these tools, and trying to figure out what they are for. And your reasoning is "tool X is for purpose Y". I know the feeling, I started out like that as well, trying to wrap my mind around what all this stuff is for. The trap is that the real reasoning should be "tool X does Z", instead. Few of these are really limited to a particular purpose.
For example. You say "Vagrant is for setting up test environments". This is wrong. Vagrant is for spinning up VMs in an automated way, including a zoo of pre-made images. "Ansible is good for servers you own" is wrong. Ansible is a tool to execute commands on a remote server where you have ssh access, with a zoo of recipes/playbooks to do the most common tasks. And so on.
This is not to berate you, but to make it easier for you. Try to be a little less abstract, and just look at what the tool actually does. Then it gets relatively easy to find proper uses, and you also can use the same too for different purposes.
For example:
Vagrant is great for also setting up development environments, not just testing. Or, really, any VM at all where you want the actual content to be mostly configuration-as-code and want to avoid clicking around in a VM GUI.
I'm just trying to understand what the need for ansible or chef are? And how about Vagrant?
Now you know what the need for Vagrant is. Vagrant literally solves the need to spin up VMs repeatably, automated, and have the configuration managed as files (i.e., checked into VCS together with the source code of your application, and so on).
Also for the build cycle CI/CD pipeline with Git and artifacts.
Read the documentation of git & co and actually look at what it does. That, then, is its purpose, nothing more and nothing less.
Same for CI/CD. Continuous integration means literally that. To continuously (i.e., once or more a day, not just every few weeks or months, as it was done in the past) integrate (i.e., merge all the branches of your application that are in development currently). There is no hidden purpose there (or if there is, it should be obvious - doing it more often means every single time is more easy, since there's not such a long time inbetween). Obviously the details of how it works exactly without turning into a nightmare could be more involved, but the purpose is just what it says on the can.
AWS, GoogleCloud, Azure ? Which is best
It does not make sense to think of "best" here. All three are extremely complex, and the fact that they are all still around means they all serve a purpose. You have to look at each of them, try them out, and compare them to your needs (and your personal likes/dislikes, sometimes).
Any recommendations about the best overall Devops setup?
Clearly the best overall DevOps setup is the one that solves your problem and fits your overall needs and wishes. There are a vast amount of possibilities of good DevOps setups, and you have to choose for yourself.
