Want to know if waeve products are in sync with what docker is to offer.
Should i go with Native networking of Docker or with weave or both; (given that the docker networking space is constantly changing)
Please let me know the tradeoffs.
Weaveworks products are continuously improved to work with bleeding edge versions of Docker and Kubernetes, as per the various GitHub repositories.
Your question about "native Docker network" vs. "Weave Net" is a rather broad, and for it to be answered properly, you would need to share more details about what you want to achieve exactly.
Feel free to detail your use case here so that the community can benefit from it, or if you do not want to do so publicly, to reach out to someone from Weaveworks on Slack.
Finally, this spreadsheet was shared at some point on Kubernetes' Slack and attempts to give an overview of various container networking solutions, so this may be relevant.
However, beware potentially out-of-date information, keep in mind the "devil is in the details" so the reality may not be as simple as it would seem according to this document. All available solutions will have pros and cons, but will also be more suitable for some use-cases than others, so always, it is a question of trade-offs and YMMV.
I hope this helps.
Related
Iām just browsing through the docs+code and I have a quick question: do you see Wolkenkit, or any of its components, working in a serverless environment? either now or in the future
Short answer
Unfortunately no.
Long answer
Unfortunately no, if we are talking about now. wolkenkit is very strict in separating your domain code from the technical infrastructure code that is required to run your domain code. Right now this technical infrastructure code is focused on making use of Docker containers, as this allows you to work not only in the cloud, but also locally, or in a classic data-center, or ā¦ you name it š
Of course it would be technically feasible and reasonable, to have another type of runtime in the future, that does not make use of Docker containers, but instead would work with some kind of FaaS solution. As the native web (the company behind wolkenkit) is a small company, we need to decide what to focus on, and unfortunately, at least right now this is not on the roadmap for the close future. I do not say that this will never be done ā it just will take time. Maybe also someone else comes up with such a runtime and enhances the wolkenkit ecosystem.
So, to cut a long story short, if now, then the answer is no. If we're talking about the future, the answer is possible, but without an ETA.
PS: I am one of the developers of wolkenkit, so please take my answer with a grain of salt.
What are the differences between DockerHub and GitHub? Can DockerHub replace GitHub or is it only for the Images? If yes, how it is different from Nexus and other binary management tools?
Smells like homework :)
They're entirely though for different purposes. GitHub is mainly though for code management, and DockerHub is though for container build, management and distribution (although not very reliable at the moment).
GitHub, indeed, went ahead of that mainly purpose of code management and now offers plenty of interesting features, but it will never be able to substitute DockerHub.
Regarding the opposite (DockerHub replacing GitHub), it is not possible at all because of the previously explained purposes. Perhaps you are thinking about some specific feature both offer, but at the moment it's definitely not something that is going to happen.
There are alternatives to DockerHub for container images distribution and building, and, by experience, far better. The only thing that makes DockerHub interesting at the moment is that it's the simplest and more intuitive platform for managing the whole process of distributing an image. Also, it's managed by Docker inc. itself, so everyone has to deal with it, tangentially or not.
If you feel like I did not get your point, feel free to comment and i'll edit this post!
See ya through the interwebz
Is there any legal restriction from docker or software vendors in using standard docker hub images in our production deployments? For example if I use ubuntu:14.04 or mysql docker image from docker hub to start containers in a commercial application, where can I find licensing details for that? Or are they merely free to use?
This is more of a legal than a programming question. Each image will likely have a variety of licenses, often GPL, but could also be BSD, MIT, APL, etc. Most are free to use if you follow their licensing terms. The most common term to consider is whether you will give out the source code of any changes you make upon request from a customer, which they are then completely free to redistribute.
Why should I consider using Rocket instead of Docker in our development pipeline. We would like to use docker to create testable containers, but now there is Rocket which pretends to know the same. If we would like to start containerization should we seriously consider Rocket as it seems it is still pretty new?
There is not much information about Rocket, so I'm no clear where it stays now in 2015.
UPDATE: from https://coreos.com/blog/app-container-and-the-open-container-project/
As we participate in OCP, our primary goals are as follows:
Users should be able to package their application once and have it work with any container runtime (like Docker, rkt, Kurma, or Jetpack)
The standard should fulfill the requirements of the most rigorous security and production environments
The standard should be vendor neutral and developed in the open
Rocket is officially dead: https://github.com/rkt/rkt/issues/4024
After acquisition by Red Hot new owner concentrates efforts on https://podman.io/
podman provides rootless containers. Something that Docker strove to get for a long time (according to the below comment, they finally managed).
As with most competitors both have their advantage and disandvantages.
Docker hub offers a public registry where docker images can be pushed and pulled with ease.
There is also now a free registry offered by GitLab! Its really good.
A core issue at the moment is security. Docker now scan their images for security flaws and report on the security status of each image.
With rocket image signatures are cross checked with the signature of the publisher to see if they have been tampered with. This affords a degree of confidence.
For a fuller discussion on security see https://bobcares.com/blog/docker-vs-rkt-rocket/
With regards standards, it seems that OCI (Open Container Initiative) has been adopted by the big players and will pave the way forward for containerisation standatisation.
We are creating a new version of payment gateway processor and We want to use docker container with kubernetes but we are worried if Kubernetes and docker container follow the PCI DSS requirements.
We don't find anything clear in PCI DSS specifications.
Re-iterating Tim's comment above: As far as I know nobody has implemented a fully PCI-compliant kubernetes install yet (they might have done and not told us). I don't know of anything specific to Docker or Kubernetes that would prevent you from getting your deployment certified.
PCI-DSS can be achieved by 3rd party solutions.
(Disclaimer - I'm an employee of Twistlock, which has brought a PCI-DSS solution, if you're interested in it please check the following link - https://info.twistlock.com/guide-to-pci-compliance-for-containers)
I've implemented and got PCI-DSS Level 1 certified a K8S Cluster as Cardholder Data Environment for the company I work for.
Don't get intimidated by the requirements, there's always a way to make them "not applicable" or meet them with some elbow oil.
The basics you need to meet to make it compliant are:
use COS so you can skip all the Nodes hardening hassle.
use the --enable-master-authorized-networks flag (Beta) although I haven't had any problems with it yet.
manage the network CIDRs yourself as you need to provide classes that don't change for the docs and show how only
those are authorized to access the cluster.
you must implement a NAT gateway cluster and pass all the K8S traffic through it and setup on the systems a silly
outgoing IDS/IPS solution, I used Suricata. (it's silly, I know)
you need to whitelist all outgoing traffic IPs for any API you're eventually calling from your apps and deny everything else.
PS: I know it sounds like BS, but you gotta do it if you wanna pass compliance.
PPS: remember to harden the NAT gateways, I used ansible with the STIG playbook.
These were the trickiest parts, everything else was cumbersome but manageable. Glad to help.
see this article. While the author is referring to "public iaas" it seems that one could substitute "private kubernetes".