Ask Me Anything

see first session and i had to forget to unmute myself we are live thank you for coming and this is the first session of ask me anything which is badly named because it's not ask me anything it's two of us there is darin who is probably going to appear at one moment there he is they're starting right so it's ask us anything right uh type of session and the first of the kind we got a bunch of questions which we are going to answer we might not be able to answer all the questions but some of them and the questions can be anything and there is we reserve the right not to answer if we have no idea in any case this is ask me ask us anything session where we go through your questions and answer them and live happily ever after if there are more questions than we can answer we are going to do this periodically maybe once a week every second week we will figure it out yet now pure housekeeping things if you have questions that you did not ask in advance ask them in the chat uh we are going to put them on the screen and then uh try to answer them so let's try to make this as interactive as possible uh and let's start what would be the first question hey can you please tell us how to perform country deployments which tools do you use oh this is an easy one there are two i will assume that you are running in kubernetes that you're using kubernetes to deploy stuff uh and if that's true uh if that's not true let me know in kubernetes there there are only two tools that matter for country deployment so progressive delivery in general that would be argo rollouts or flagger argo rollouts is part of argo farm family and flagger is part of wework's set of products both of them are amazing both of them are good i cannot say which one is better you cannot go wrong with either of the two usually people choose depending on whether they adopted flux for githubs or argo cd for githubs as well so depends which family you choose uh next one what are the tasks we can perform on solar cube as devops engineer could you please explain some videos on sonic you for python projects unfortunately i haven't used solar cube for years now i'm not sure that it whether you use sonar cube recently i have you have experience with it i've got some experience with it but i haven't used it real recently so sorry for that i think that i'm seeing solar cube less and less i think that it is slowly fading it is still very much present in big enterprises but it is slowly fading and i think that okay so here's the deal here's the story that is not really directly related with solar cube i think that those tools have very limited value people get hooked on to hey what is our test coverage what is our uh completeness what is this what is that and really forget that it's not really about test coverage it is not about the percentage of successful or failed tests for at least two reasons first of all it's about quality of testing of the coverage i would have rather 20 coverage with tests that are doing the good thing the real thing then a hundred percent of coverage of tests that are useless especially tests that are flickering will fail for random reasons second reason why i don't think that those tools are exceptionally good is because if you exclude legacy projects which is would be a separate subject and we i can talk about it just let me know in the comments uh i think that uh uh successfulness of tests should be either 100 or not 100 if tests fail you need to fix them you cannot go and say hey we are successful because in the past we had 44 of the tests that were failing and now we have 30 percent of the tests that are failing which is what sounder cube gives you in a way so uh i really think that it should be binary either it's successful or fail i don't care to see about percentages of how how many failed either they failed or they didn't right that should be the logic that we should strive for and if you have tests that are flaky that are constantly failing for random reasons and are not reliable then remove those tests it's better to remove the tests you don't trust then to keep them for some statistic purposes what is the best way to learn devos by myself without joining a company the best way without doubt is watching this channel [Laughter] but on a serious note i don't have a good uh good recommendation i think is just about really taking things one by one figuring them out and most importantly it's about uh figuring out how those tools fit together right uh and i think that that's kind of where people tend to fail uh it's it's it's not about learning five tools it's about figuring out how those tools fit together into a processor system what's or not right that should be really a goal whenever you pick up a new tool from the bucket uh after spending maybe a a day figuring out the basis of the tool the most important thing especially if you're talking about devops is how does that fit into the big picture right so i i tend to always put myself a task apart from evaluating a tool apart from figuring it out i always spend just as much or more time trying to figure out where in the picture it fits what it should be combined with where in the process it should be placed in and stuff like that right so it's really mostly about you know learning a tool it's easier just go to readme and figure it out uh or yeah learn how it will follow the description uh figuring out how it fits where it fits that's the real challenge now before we go to the new question very quick housekeeping uh since recently like a couple of weeks ago i enabled the donations to the channel which helps because this happens to cost a lot in equipment and editing and what's not and you can also join the channel become a member uh there aren't many perks let me tell you that in advance uh except that we have we will have member only meetings uh so it's not much about perks but it's about you showing that uh you want to support the channel with your money not much it's less than a coffee though anyways what's the next question oh uh if you program java would you use intellij idea or vs code uh vs code so i might be wrong actually uh i might not be saying the correct thing uh darin is going to jump in so i haven't been working with java a lot you know while uh but the reason why i said vs code even though i'm not really working much with java is the ecosystem around vs code right it happens to be present everywhere if you pick up let's say git pod uh to do whatever git put is doing you're going to see vs code if you pick up this tool you're going to see vs code it's becoming a black hole with the gravity that is almost unavoidable and now drawing is going to going to prove me wrong i'm not going to prove you wrong i would say today literally this day i would still stick stick with intellij if i am doing hardcore java development vs like if i'm just doing some starter kit type stuff vs code is fine but there's enough built-in tooling and because intellij has been around for so long it's going to still serve you better from code completion and it's just more functionally rich just because it's been out longer i'm not saying either is right or wrong i'm just saying if you need those extra helpers intellij tends to be a little bit better today i must concur simply because i'm not using java for a while now yeah so should we put one of the questions from before and then moving back to the live questions kind of mix them up a bit because uh fyi for everybody we were collecting questions from you for from you for a while uh and there's a bunch of them so let's mix them up a bit okay so here's one that we got from [Music] i'm not even going to try the name so forgive me yeah name set out to the questions i cannot pronounce him or my name correctly we never hear microsoft in your videos how come now the answer that that is relatively straightforward um actually it's not straightforward what am i talking about most of the things i do are not really directly related with not only microsoft but actually i assume that you're talking about azure now not microsoft if you're talking about azure i rarely do videos specific to azure aws or google there are some exceptions and in case of azure i did the one about container instances i think is the name and a few others and i might have done a bit more from google but in any case if you have a suggestion about specific service or product or anything from microsoft uh just let me know and i will do that i did github actions of course uh that's microsoft i did the one about github cli you're not right i did actually now when i think about it if i include everything from microsoft i think actually did probably more from microsoft than from uh others of other by others i mean google and aws i'm just forgetting microsoft is so big that you don't even know which tools they have anymore right github is there github action says there's uh cli is there's visual studio code is there's it's everything now you're stretching i think his question might have been towards why aren't you talking.net iis that ecosystem system of microsoft okay that might be as well uh i rarely talk about programming languages right it's more about tools yeah yeah do we go back to the live questions yeah okay let me do that let me figure out where were we we were right here oh this is the next one and i'm going through these in order so as sure if your question's already there don't ask it again uh we're just going through from the top so we'll get to it or not depending on if we run out of time so what do you think about this are there any practice projects i've seen some that are from a security perspective it's like a completely busted kubernetes project but besides that i don't know i don't know to be honest i have no answer that question be mostly because i tend to pick up tools in their very early stages when there are no such things and then when practice projects for something kubernetes or anything else come come along i'm probably very deep into it so i have no answer to that question i'm sorry really nothing okay nothing i don't know a funny kubernetes practice project that's really the same i'm disappointed in myself now do you have your notebook beside you yeah write it down no i don't but like a visual studio that's right okay got it all right um just a couple of things hi from morocco how are you doing there is our friend eric how are you doing here hey which beer that's a valid question which period am i drinking san miguel okay i i'm not sure whether that exists outside of spain i don't know and i don't drink so i no no beer for me uh good vibes can you make a video on helm chart deployment this is interesting yes don't you have definitely i don't actually i have it in the course but not in the youtube channel so the the course the devil's catalog something something the last one we did there is a book actually as well uh here's a section about helm specifically and since we did it there i never thought to revisit it until now as uh for youtube uh so i did it to my to our to-do list and uh i cannot guarantee when though but yeah that's that's something interesting that we might want to do again do you believe true devops can be achieved in an air gap system on a network that is not connected to the internet uh definitely yes but our definitions of devops might be slightly different right uh by devops i consider first and b be before anything else uh self-sufficient teams that contain both development operation and operational knowledge whether that's one person knowing goal or a team that has all that experience is is a separate subject uh and then being able to be self-sufficient to develop deploy test monitor yourself and when i say yourself meaning your team up to 10 people never bigger than that i i think that that that is that is just as achievable in air gap system as in not air gap system right i don't know i don't know that one i don't know what's the best firewall for kubernetes to be honest uh that happens whenever i was in situations like that that was done by somebody else so i haven't had practical experience myself sorry for that there are many things i never tried do you have thoughts about best practices for github spare metal deployments uh now i assume that today if you're starting from scratch i mean it's still kubernetes right uh so it's more about uh and this is kubernetes we're still talking about uh correct me frog it might jeff it might not be kubernetes but if it's kubernetes on bare metal then the rules are the same you will still use uh argo cd or flux store your manifests in a git repository let them figure it out and that's for applications now for configuring those bare metal deployments you need something that is dealing with infrastructure or configuration management and then you would either use something like and this is this is now uh i'm fi i work for a company that is behind the project i'm going to mention but you can use crossplane that is that that can work with bare metal as well at least some of them and if not you can uh you can create a provider and if you want to go with something something else then you would need to change the direction uh since github's in most implementations is a pool based mechanism something running in your uh in your server in your cluster pulling manifest from git uh you might want to reverse that and go more for pipeline type of stuff instead of github's type of stuff you would trigger uh trigger process whether you're using ansible terraform cf engine puppet whatever you're using to manage those uh bare metal uh servers right but now actually now just notice that you're saying yes with it in bare metal deployments it really depends whether it's kubernetes or not if it's kubernetes flux argo cd still works doesn't matter that spare metal if you're talking about direct deployments like ssh then we're talking about pipelines rather than than really githubs let's cut over to one of our previous i'm not i know i'm not okay but that's okay let's go to this one oh oh oh oh that 10 000 feet overview of current kubernetes developer platforms available pros and cons that's big so there are i would say that there are three types of uh platforms or or maybe more than three um there is use kubernetes directly right and uh that would be directly eks aks uh jk the red cat rancher whatever right uh and i think that that's not really that wouldn't qualify as developer platforms for a simple reason because they themselves alone do not provide tooling sufficient to enable developers to use those platforms simply because kubernetes itself is too complex uh for us to to do that and i do think that kubernetes was never meant to be used directly right uh kubernetes is more like a set of building blocks to create what you call here developer platforms so our options are essentially like with anything else you go with something highly opinionated or you build it yourself right and both have pros and cons if you go with highly opinionated then you you need to adapt to the opinions of that platform right so you you get the platform opinion the platform that can be anything from openshift openshift is somewhere in the middle it is actually opinionated but also allows you to tweak it or you go with the google cloud run with qualifier think with that category as well and a few others so opinionated you need to adapt to it once you adapt to how the platform works then you get if you can adapt you get great results almost from day one alternative and where i think we are going uh is be able to create opinionated developer platforms yourself so rather than choosing a tool that is already ready to be shipped shipped to developers to choose the tool that allows you that allows you like sre sysadmin operator whatever you are to create the developer platform yourself and that requires more work obviously but the results are usually better because then you can create a platform that specifically fulfills your needs uh and that's where i think that we are going is industry and that's where uh that's those are the kind of two categories above kubernetes itself highly opinionated out of the box experience you need to adapt to it or build your own uh huge potential huge investment initially better results later assuming that you know what you're doing right um and that's very i think that in a few years time we will not be seeing kubernetes anymore i think that kubernetes will become an implementation detail just like the example i tend to use often like hypervisors right hypervisors are extremely important many of us had to work directly with hypervisors 20 years ago or 15 and today no almost nobody knows what hypervisors are simply because we work directly on a higher level of abstraction which are vms okay um let's go back here about this one how do you respond to people who complain that kubernetes is too complicated that's a good one as well here hey kubernetes is too complicated respond um it is but based on what you were just talking about from the 10 000 foot view was it done did we do it to ourselves so usually answered with the be the question to that question and that question is is there an easier way less complicated way to accomplish the things that kubernetes gives us because comp saying cooperatives is too complicated is true it is complex because the things that it does are complex but the real question is two questions actually do you need what kubernetes gives you if the answer is no then don't use it do you need auto scaling do you need fault tolerance do you need higher availability do you need all the things that kubernetes or some of the things that kubernetes gives us the answer is no then the answer is don't use it it is too complex for your needs and what you need is something much simpler than kubernetes just uh let's say aws slide sales use light sale light sale is so much easier than kubernetes it gives you it doesn't give you the things that kubernetes gives you but it's much simpler now if you do need what kubernetes gives you like you know encryption on the networking layer uh ingress uh autoscaling all the things i mean not all some of the things that kubernetes gives us my counter argument is that there is nothing less complex than kubernetes kubernetes is the simplest solution we have today for the things it does okay hi both and takes in advance we're moving from a bunch of one 630 docker compose approach to rancho to four that relies on kubernetes any good practice to follow that you can suggest uh yes you will need to learn kubernetes unless you already i'm assuming that uh some people or all i'm sure about your context uh are used to docker compose because they're not familiar with kubernetes and once you move there and simply there is no magic bullet you will need to write your kubernetes manifests uh either directly most likely you should use helm or customize uh there are videos in this channel to compare them there are pros and cons of both so you need to figure out many things it's going to be a painful transition the important thing is that once you move to kubernetes and simply you you cannot not move to kubernetes because there is no future for docker compose in production absolutely not right that's that's that's never going to come back so kubernetes is the only option you have uh and there is no advice except you will need to spend time figuring out how kubernetes works it doesn't really matter that it's rancher that's that's completely relevant in that story it could be anything else what is important is to eventually sunset compose and do not keep using it locally and i see that all the time people say hey compose is easier than kubernetes it is absolutely and therefore and we have to use kubernetes in production understandable therefore we are going to use docker compose locally and for local development and kubernetes helm customize whatever you're using for production and staging environments and whatsoever and that happens to be more complicated because the real complexity is defining the manifests of everything you need right and there are tools to help you those opinionated tools that i mentioned before like shipa the previous company i work with allows you to kind of like skip that part which is also risky but anyways once you once you transition your production to kubernetes from there on local development from kubernetes becomes just as easy or easier than compose which might sound counter-intuitive but think about it once you define the manifests hemp charts whatever you're using in kubernetes then it's just as easy to run helm install as docker compose up and the added benefit is a couple of them first you don't you do not need to define the same things twice because those are incompatible formats you do not need if you already have kubernetes manifests for production why would you maintain compose manifest for local development that makes no sense to me uh second uh your local development will be much closer to what your production is it's never going to be the same but it's going to much be much closer so if there is one advice that is not to keep composed for local development uh many people do that and i think it's a huge mistake uh when should you use vpa over hp and kubernetes i'd imagine that there are cases where you must use both but i can't think of any i personally haven't found an example of actually there is there is a use case where you might want to use both so let's go first one by one right uh horizontal hpa is horizontal plot autoscaler which means that when you need more of something a new replicas of that something are created right and vertical pod autoscaler means that it will increase the membrane cpu of your application uh and scale it vertically so instead of creating new replicas of your application it will uh increase the the limits of memory and cpu now the reason why you might want to combine those is to save on resource uh utilization right because let's say that your application can handle up to four gigabytes of ram right uh that that's that's the limit after which you want to scale horizontally so the scenario would be when you reach four gigs of ram after that we see degradation in performance scale horizontally however with a vertical put out a scalar you might want to set that hey i start with one gigabit and then go up to four and then as you as as vpa is adjusting that kubernetes is also adjusting because if you start by setting four gigs of ram in that fictitious example kubernetes will allocate four gigabytes of ram uh for that application even though it might be using only four right so for better for helping kubernetes better allocate resources to that application you might want to use vpa but the hpa is the key always in ls application cannot really scale horizontally then there is only one chain one choice that's vpa i want to take a second and talk about uh the channel again oh yeah so again the channel i have i have icons for everything now i got animations that's why we need you to support the channel because people are paying people to do the animations you're seeing right now so like it subscribe to the channel do all the things that you typically do and on top of that uh now we accept donations it's up to you to choose how much you donate and we are really really really grateful for any of them and you can join the channel become a member tiny tiny tiny fee you choose which one you want to do and basically by that you're showing that hey this is useful to you uh and i want to help the channel uh financing and trust me neither mir nor darin are getting rich of this this goes to covering expenses at least right now stateful set example stateful set example please so the two people before the session those are the comments from before asked about stateful set examples and now i am unfortunately not really prepared so we are going to wing it a bit but first i'm going to share my screen and then uh darren is going to add that screen that we can see there we are okay so here's my github repository let me see one repo that i have some example uh here we are specs i think i must have something here let me find an example of stateful set this is from one of the books uh that we wrote long time ago so let's see this one right now specification what's this question of specification i think specification is almost the same as deployment right so if you would change the word stateful set to deployment there would be almost no differences between stateful set and deployment there are a few but they're not really important so no difference or close to no difference between stateful setting deployment in a way how we define it the differences are in how they work and there are two major differences between stateful set and deployment the first one is how volumes are mounted so if i have here an example with three replicas now if this would be a deployment this volume mount would volume mount actually would mount a volume one volume to all three replicas so all three replicas of that deployment would share the same volume and in this specific example that i'm using that could not work i could not make work as a deployment with three replicas and one mount simply because each instance of mongoose mongodb needs um needs a unique let's say uh volume because they cannot write on the same file system on the same files now if this would be stateful set as it is those three replicas would get a volume each so in this example the the three replicas there would be three pods one representing each replica and each of them would get the unique volume mounted right the second difference between stateful sets and deployments is in naming and the order in which things are happening so the if you have three replicas of a deployment naming would be in this case how do i call it db uh would be db and then dash and some random hash unique hash string in case of stateful sets it would be db-1 db-0 db-1 db-2 and that's important because when you have stateless end actually before i go into important part uh and they would always start in that order uh dbo first db1 second db to third and then when you update them or shut them down they would be shut down in the inverse order three two one zero so you know the order in which things would be created and things would be shut down or things would be updated and that order tends to be often important for stateful applications so the order of creating pods uh destroying pots updating pods what's or not and uh volumes being mounted in each replica instead of one replica all replicas sharing the same volume those are the three two major differences i want to test something here hang on a second uh we have oh we actually have a new member tt joined up as a new member and he also had uh derhazi please give me if i said that wrong so thanks for joining the channel we appreciate it oh welcome thank you so much hey wait there is up if you go up in comments there is dor sivan as well oh really and oz oh yeah i cannot pronounce yeah so there was became a youtube member uh see this is so our other channel doesn't get this type of information so well we haven't had members so yeah we don't know until now we didn't know we're using new tools yeah so we have new tools okay cool um let me get back to the next question are you okay on stateful sets i sort of butted in there because i was trying to figure out yeah this works yeah i don't know perfect this is so random uh let's see how as we go let's talk about this let's uh any guide on or recommendation on how to implement prometheus stack using argo cd i'm not sure what to mean santiago i don't have anything special unless you have a specific issue to be honest because it's argo uh prometheus stock is just a set of kubernetes manifests you store those manifesting git and argo cd manages them uh the only thing that is important to know is that sometimes and i'm not not talking really directly about prometheus but in general sometimes you might want to tell argo city to exclude certain fields from its calculation because in some cases the first example that comes to my mind would be argo rollouts or fl or flagger that sometimes the definition of a resource in kubernetes is changing at runtime and that might be the case with prometheus and then if it changes at runtime then uh argos editor flux uh would undo those changes because it says hey this is not what you're defining it so sometimes you might want to exclude certain uh parts of the definition um from um from argo cd or uh or flux that's the only thing that comes to my mind if you have something specific let me know otherwise treat it as any other kubernetes resource cool and we've got a couple of super stickers here got a super sticker from chris thank you and a super sticker from tt as well wow thank you so much thank you thank you thank you um let me get back to the that we need to now now that we're getting stickers and what's not we need to figure out all the currencies in the world we should yes um i i i can learn it i can learn it uh i want to go back to i saw a question i can tell you today we're not going to get through all the questions uh so victor make sure since we're this is our first thing don't trim this video because we need to hang on to these chats we need to capture all those before we trim it out yes so and can we commit right now that we're gonna do that as long as uh questions are coming i don't mean today but kind of yeah weekly weekly basis something like that something yeah basically we'll figure it out schedules yeah we just don't know exactly what that's going to be yet let's let's get to one of tt's questions here or another one of them what's the benefits of using labels oh to begin with before we go into benefits labels are the gluing kubernetes you cannot not use labels in a way right and a good example would be deployment kubernetes when you create a kubernetes deployment kubernetes deployment creates a replica set a replica set creates pods and they all know how to do those and what is the relation between all those all those resource types true labels so when you create a deployment you tell it hey those are the labels you should monitor for and use when creating a replica set and when you create the replica set and and you're telling replicas that hey create those pods and track those spots through the labels so labels are how kubernetes resources are tracking the parent-child relationship and there is a lot of parent-child relationships one resource is creating another another creating another and so on and so forth so that's kubernetes way of tracking that relationship and on top of that uh you might from human perspective uh or from not only human perspective but from tooling perspective labels are also essential like uh a previous question mentioned uh prometheus right uh when you start querying metrics of your of different entities of your your kubernetes cluster you're going to do that most likely through labels initially you might say hey let me see what this thing with this name is doing but the that's the you're going to soon discard it to begin with names are uh kind of names include hashtags in in in kubernetes because you're almost never creating a pod so you don't know what is the name of the pod you're going to find that pod through a label and after that you're going to impromise at least you're going to discover that hey i'm not i don't want to track one pod i want to track a set of pods a set of services and so on and so forth so it's a filtering mechanism both used internally by kubernetes and uh by you through other tooling you will be using the same thing goes for logging and then almost everything else it's how we filter stuff in kubernetes through labels so i'm gonna go ahead and butt in here we got a five dollar super chat from g vodden thank you thank you hi from canada can you do a video on kubernetes certifications uh no because i'm not certified myself so i don't know how to work are you certified that no i'm not certified so i'm not saying i i don't know i never took a certification i have no idea uh i would like to know that gordon but i don't know how i would need to make okay so here's the deal if i ever go to vacation and i i don't remember last time i was on vacations and i decided not to work on vacations i will take the certification exam myself and then i can do something around it okay and uh thanks to prakash for becoming a youtube member as well thank you let me get back to where we work so i wanted to get to i saw a question from neil that i wanted to bring in uh neil is one of our regulars over on devops paradox here i guess i could pull myself up here and um i am good grief okay here hang on this ui has a little b to to be desired okay here we go there's neil's question argo best cd excuse me argo cd best practices suggests go for it config from source code okay i actually just had this question not specifically around argo cd but i had a meeting this morning that goes specifically to this scenario of separating configs from the source yes wow what i had quite a few conversations on that subject sometimes very heated right because people have different preferences i will tell you mine right and explain why that preference is that preference so i start with the premise that uh a code of an application is in a git repository and when working with that application we need to have more than code we need to have tests there because we are running tests it's very unconvenient to have tests somewhere else right for that specific application we have build scripts because while developing we need to build something we have deployment manifest because while developing we want to deploy that something what i'm trying to say is that i think that a repository of a single application should be be self-sufficient and have everything that that application con needs and that cannot include everything except deployments except the manifests uh that describe that application and uh for kubernetes right so my initial premise is that it makes sense that manifests of the application are in the repository of that application but what doesn't make sense is that uh information specific to an environment like this is how we tweak that those manifest that application for production is and this is how we tweak and customize that application for staging is simply for a couple of reasons first if we keep the production specific manifest in in the rip of of the application then we are going to enter into a loop from which it is very hard to get out uh so imagine you push something to that repo and that triggers a pipeline or whatever that uh builds something builds a container image run tests what's or not and then at one moment it needs to update and say hey the tag of that application running in production is this one push that change to get if that change is pushed to the same repository then that would initiate the same pipeline over and over and over and over and over and over again right and even if you circumvent that even if you solve that problem of infinite loop it would still in my head and i might be wrong but not make sense because what i want when defining an environment is to know what that environment is right hey those are the 57 applications we run in production those are the specific tags specific hosts and all the things specific to production so in other words what i tend to do is have a repository for each environment and let's say that i'm using argo cd uh same same would approach the same story would apply to flux as well right so i have production environment that says argo city application manifests that references the manifests of that application in the repository of that application and then overwrites the things that are specific to production like this is the domain this is uh this this is that whatever things are specific so in other words one repository for each environment manifesting those repositories are referencing manifests that are in the repository of specific application right so the number of repositories in total would be the number of applications plus the number of uh environments okay uh i'm gonna try something here no that doesn't work i wish that that would work okay so you actually have a new member uh morrison thank you for hey thank you um okay and this is sort of like i'm heading back up but i saw this one are developers overrated um no they're underrated they're underrated i think that uh all the people working around the industry are developers everybody's writing code i think that people not writing code are overrated right these days we're moving into area that does not matter what your specialty is whether you're specialized in testing in front end in back end in databases in infrastructure in this and that you're writing code and if you're writing code you're a developer the i i do not consider only people who write front-end applications developers right user external user facing front-end applications that can be internal usage there are people who write services for internal usage internal platforms managing infrastructure we're all doing that through code so everybody's developer so if developers are overrated then everybody in us in uh related to software development uh is underrated okay um and we've got about 12 minutes left and we are into the fifth minute from the top of the hour of questions so obviously there will be another session like i said i keep forgetting to put myself up see i'm i'm playing producer role today i'm not playing talent today and shall we switch next time no i don't want you pushing the buttons okay so this is a question that i think is is a good one but i'm going to simplify it is it valid to set up x to build images and why to deploy them i was about to say that there is i would change this question is it a valid to use pipeline tools to build images and github's tools to deploy them that would be a more generic i think valid question right and the answer is yes and i dislike i don't like that argo cd has the word cd over there because that's not cd and i don't like that flag cd is having cd there because it's not cd cd is done through pipelines because continuous delivery continuous deployment whatever you put behind the acronym cd is about automating the full life cycle of an application or maybe a service or infrastructure whatever that is from beginning to the end and deployment is only a part of that because we need to uh get the code we need to build something we need to store that something somewhere let's say we need to build container image we need to push that image to a registry we need to run some tests and we need to deploy that's a bare minimum and each of those stages can be multiplied by many times and so on and so forth so the major change i think uh from pipeline tools and how we were using them before and now is that traditionally those pipeline tools at one moment would execute a command like cube cattle apply help install uh customization that whatever the the deployment mechanism uh we were doing using in the past what pipeline tools are doing now only for that part they're doing much more right but related to deployment are getting the code of that environment specific repository that i was measuring before clone it modify some manifest push it back right and then then argo cd or flux would make sure that that's synchronized effectively do the deployment i don't like to even use the word deployment anymore because it's a bit misleading but yeah do the deployment uh so yes uh it's a perfectly valid the short version of the answer to your question is yes we got two new members here we have nitton and we have kenny thanks for joining up to the channel well i like the last name it says long long time youtube member i almost misread it oh right that is pretty funny um let me find so this is okay y'all stream yard i love you but there's i need to be able to get back where i was i know you're working on it but it's a little challenging uh let's see here where was i believe this is chris's question yeah this is one how can you handle privileges or secure credentials in a team should each team member have full privileges on all production services wait i have an answer for that okay that's called that's that's no um included in central okay so how should you do credentials it's 2021. should you use a service that does what it is so let's start with the ideal situation ideal situation is nobody has privileges to access anything from security perspective that's the ideal situation right now from from productivity perspective traditionally that's a horrible situation because if i cannot access anything that then i cannot do anything because uh i cannot access anything therefore i need to always delegate ship you know throw over the wall to tasks to specialized themes that have specialized privileges now this is where the previous subject of github's i think kicks in how about we do both you can do everything you're allowed to do your you should do without being actually able to access anything and that means that we run our pipelines that build stuff do things uh in specialized environments we'll call it ci cluster or whatever right a cluster environment that can build things you know that's already solved for a while now but instead of you or other tools accessing directly production to deploy things you push things to get and if you're not supposed to view as a person or a tool if it's not supposed to deploy directly then instead of pushing to the main line create a pull request if some if there there should be a human approving that merge that that human that person should merge that pull request so what i'm really trying to say is that we are now in a place where you can be as productive as you would be by having full access to everything without having full access to everything simply because we have tools that can interpret your intentions defined and pushed to get and do the things for us okay uh let's see if we can get two more in real quick what are your top three kubernetes tools or projects i might i didn't think about this in advance so i might change uh but after thinking a bit i might change my opinion but let's say the first the first ones that come to my mind uh would be argo cedar flux i think it's absolutely amazing essential everybody needs it um what else what else um it's difficult to say really there are more than three uh prometheus is unavoidable kind of i think that it should be baked into kubernetes in one moment right uh i'll uh promote this would be second probably and then uh hellmore customized qualifies kubernetes projects without them i wouldn't be able to do anything okay let's let this next one be our last one for today and again we'll capture all these and figure out when we're going to do this next it's hey for me i know it's not going to happen next week so victor if you're going to drive by yourself you can do it but i can't next week figure out we'll figure out what it is it may be two weeks or something but anyway uh for everybody that's been here with us live today thanks for being here uh here's the last question for today and again we're capturing them all so we'll get we'll get to them it may take time so would you recommend using argo for data pipelines why not yes i would recommend it so i let me say that first that's not the main area of uh that i'm involved in so i i'm not as deep as data as in other things uh so i might be wrong but i would probably from what they know from second hand rather than practical experience i would probably choose argo over over those that you mentioned therefore perfect duxter i'm not saying that based on experience i'm saying that more at looking the adoption rates looking the interest uh that people uh look into those things have and things like that so i might be completely wrong by the way um data is not my main focus but i would say yes and one more thing the among other things so i'm not following so i don't know who is exactly using argo i know that many and i think that this is now referring to argo workflows for data uh processing pipelines what they do know is that argo was born uh in into it uh and they use it they made it for their internal purposes and precisely to handle data data pipelines on massive scale right so it was born from the real need used by a real company that happens to outsource it without really looking into some commercial interests so i as as a minimum i know it solves one company's problem at a huge scale as a minimum right okay uh that's going to need to be it for today victor since this is your show and your channel nice you just don't appear in it i just don't appear in it i'm i'm pulling the strings in certain places uh so i'm gonna let you close this out again this was the first one that we did so we don't have all the cool bells and whistles but victor does have some cool bells and whistles and then i'm going to step out let victor close it up and it's going to be very abrupt when it closes so we don't have anything cool at the end so victor here you go thank you all so much first of all i'm overwhelmed by that how many of you came in uh i'm overwhelmed with the number of questions we had uh and the support and and the you becoming members and the stickers and all this stuff i'm really overwhelmed i did not expect this this this is absolutely amazing and we're definitely going to do this on a regular cadence because there are much more questions than we could answer in one session uh we just need to figure out the logistics when how to be announced but thank you all for joining thank you all for being here and thank you all for support really really really appreciate it is that it that's it i'm not prepared that's the the only thing that came to my mind okay so wave by victor look in the camera look at the camera and wave goodbye goodbye thank you

Channel: DevOps Toolkit by Viktor Farcic

Views: 1,480

Rating: 4.9322033 out of 5

Keywords: ask me anything, containers, software development, devops, gitops, kubernetes, k8s, docker, infrastructure as code, iac, continuous integration, continuous delivery, continuous deployment, ci, cd, devops toolkit, viktor farcic

Id: 1bKFNDU8dpA

Length: 58min 44sec (3524 seconds)

Published: Thu Sep 23 2021