good morning. I'm new to docker, kubernetes, terraform. I need exercises to practice. I would appreciate the help of some of you whether in advice or links to sites where I can find exercises.
Related
I have a monolithic application based on .NET , the application itself is a web based app.
I am looking at multiple articles and trying to figure out if the Azure CI or similar would be an correct service to use.
The application will run 24/7 and i guess this is where confusion comes in, wouldn't it be normal to have always on application running on CI?
What i am trying to achieve is a container per customer where each customer gets one or more instances that he owns. The other question would be costs and scalability, i would expect to have thousands of containers so perhaps i should be looking at Kubernetes ?
Thanks.
Here is my understanding. I'm pretty new to both ACI and Kubernetes, so treat this as a suggestions and not a definitive answers 🙂.
Azure Container Instances is a quick, easy and cheap way to run a single-instance of a container in Azure. However, it doesn't scale very well on its own (it can scale up, but not out, and not automatically..), and it lacks the many container-orchestration features that kubernetes offers.
Kubernetes offers a lot more, such as zero-downtime deployments, scaling out with multiple replicates, and many more features. It is also a lot more complex, costs more, and takes much longer to set up.
I think ACI is a bit too simple to meet your use-case.
I apologize if this is an ignorant question but I am building out a Kubernetes cluster and I really like the idea of abstracting my computing infrastructure from a single cloud provider and steering away from a VM platform but what about statefulness? I want to be able to setup a mysql server for example and keep that data for life, I want Kubernetes to load balance a mysql container with a data drive, we speak about containers and we think life and death within seconds but what about when we want to keep data around and build a kick ass data center without VM's is there a concept of of being stateful in this paradigm?
Kubernetes provides StatefulSets for Deploying stateful containers like databases. Follow the below link to understand how to deploy mysql database In highly available mode
https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/
Not ignorant at all, in fact, stateful apps (often DBs) require special consideration in Kubernetes.
StatefulSets are one of the primary Kubernetes objects that exist to help support the use of stateful apps.
This is a decent guide to solving some of the challenges. It's written by Google for Kubernetes Engine but the concepts apply to Kubernetes broadly. There is also a GKE-specific overview.
I'm starting with Kubernetes (through GKE) and I want to setup Gitlab Review Apps.
My use case is quite simple. I've read tons of articles but I could not find clear explanations and best practices on the way to do it. This is the reason why I'm asking here.
Here is what I want to achieve :
I have a PHP application, based on Symfony4, versioned on my Gitlab CE instance (self-hosted)
I setup my Kubernetes using GKE into Gitlab
I want, on each merge request, deploy a new environment on my cluster where I am able to test the application and the new feature (this is the principle of Review Apps).
As far as I read, I've only found simple implementations of it. What I want to do, is deploy to a new LAMP (or LEMP) environment to test my new feature.
The thing that I don't understand is how to proceed to deploy my application.
I'm able to write Docker files, store them on mi Gitlab registry, etc ...
In my use case, what is the best way to proceed?
In my application repository, do I have to store a Docker file which includes all my LAMP configuration (a complete image with all my LAMP setup)? I don't like this approach, it seems strange to me.
Do I have to store different custom images (for Apache, MySQL, PHP-FPM, Redis) on my registry and call them and deploy them on GKE during review Stage in my gitlab-cy.yml file?
I'm a little bit stuck on that and I can't share code because it's more about the way to handle everything.
If you have any explanations to help me, it would be great!
I can, of course, explain a little bit more if needed!
Thanks a lot for your help.
Happy new year!
we are in the process of dockerizing existing services those use kafka, storm
and the expectation is use to create dockerized builds by integrating with jenkins .
I happened to look at a couple of articles http://blog.howareyou.com/post/62157486858/continuous-delivery-with-docker-and-jenkins-part, they are helpful.
I wanted to know the experiences with docker and how much time it took for the dockerizing a typical solution. And are there any best practices ?
There are lots of best practices: https://docs.docker.com/articles/dockerfile_best-practices/
I think the "time to dockerize" will depend a lot on how familiar you are with linux. If you're already used to setting up linux systems, it should be pretty fast.
Our team is just starting to experiment with Vagrant as a way to manage our development environment across a very diverse team (multiple developers, designers, UX engineers and stakeholders), so it seems like the perfect solution for us.
Due to the diversity of the team, I would prefer to be able to avoid the part of the Vagrant process where the user needs to SSH into the VM in order to start the server. I know that it's possible to edit the startup files (We're using Ubuntu as the VM base) for the VM, and also that it's possible to edit Vagrant plugins, and based on what I'm reading, it appears that both possible solutions can give us the desired activity. What I don't know is what's considered the best practice for this problem. I'm very new to the Vagrant space, so I'm reaching out in the hopes that someone can provide insight as to what the best way to accomplish this goal is.
Or, if anyone knows of a reusable example of how to accomplish this goal that's floating around, that would be appreciated as well.
Thanks in advance.
We ended up simply writing Vagrant plugins right inside our Vagrantfile for the project. Perhaps not the best way, but effective for our personal situation.