Welcome everyone. My name is Lekha Jeevan. I'm a software developer in test with Rackspace and I'm Glyph also a software developer at Rackspace Today Glyph and I are here to talk to you all about Mimic an open-source framework that allows for testing of OpenStack as well as Rackspace APIs Mimic has been making testing across products in Rackspace a cakewalk And we think it could potentially do the same for OpenStack-based applications as well someday today We're not there yet, and your contributions will help us get there soon. I Originally created Mimic to help with testing Rackspace autoscale because I hate waiting for tests to run Also, I was creating it as I was creating it I realized that it could be something that could be reused for multiple projects across Rackspace and OpenStack and Glyph volunteered to help achieve that. I saw Mimic had a lot of promise But needed some help with its implementation. So I came on to the project and I've been helping improve its architecture Making it more generic and modular So before we even begin to dive into the details, let's take a quick sneak peek at What Mimic does and how easy it is to get started with it. So in a virtual amp we pip install Mimic run Mimic and Hit the endpoint and Mimic returns the authentication endpoint to be able to authenticate and get the service catalog of All the services that Mimic implements While today Mimic is for a general purpose testing it was originally created for Rackspace autoscale So let's talk about that and see why we needed Mimic So Rackspace autoscale is an open-source project a solution that Rackspace utilizes To automate the process of getting the right amount of compute capacity for an application By creating a deleting service that is scaling up or scaling down servers and associating them with load balancers In order to perform these tasks autoscale depended upon three back-end Rackspace APIs one was the Rackspace identity for authentication and impersonation cloud servers for provisioning and deleting servers and Load balancers for adding and removing servers from the load balancers as they were created and or deleted Rackspace identity is API compatible with OpenStack identity v2 and Rackspace cloud servers is powered by OpenStack compute Rackspace cloud load balancers is a custom API as Autoscale was interacting with so many other systems testing autoscale did not mean just testing features of autoscale But also that all the systems that autoscale depended on if any of them did not behave as expected Autoscale did not crumble and crash but was consistent and able to handle these errors gracefully So there were two kinds of tests for autoscale One was the functional test that validated the API contracts these tests verified that the autoscale API responded accurately for given valid or malformed requests and the other was the system integration tests These were more complex tests these verify the integration between autoscale and Identity compute and load balancers for example when a scaling group is created one one such test would verify that The server on that scaling group is provisioned successfully That is that the server not only went into an active state, but also was added as a node to the load balancer or If one of those servers went into an error state Then that autoscale was able to reprovision that server successfully and then added to the load balancer in the scaling group So all these tests were set up to run against our production environment and here are some observations I had whilst writing these tests Servers could take a while to build sometimes five minutes sometimes ten minutes or longer and the test would run that much longer and Sometimes tests would just fail randomly because a test was expecting a server to go from build state to an active state but the server would go into an error state and Test for such negative scenarios like actually testing how autoscale would behave if a test Server did go into an error state could not be tested because it was not reproducible consistently However, the overall test coverage was improving and I continue to add tests oblivious of the time it would take to run the entire test suite and later we even added these tests as a gate for autoscale's merge pipeline and Things were not going so well because tests were slow and flaky and nobody wanted to run these tests locally because not even me when I was adding more tests and Our peers from computer and load balancers were not happy because we were using all of their resources for our autoscale testing and They were so not happy that we were pretty glad we were in a remote office But we had had enough this had to change we needed something to save us from these low flaky tests So now that we've had enough how are we going to solve this problem? Since we've been proceeding from the specific case of autoscale to the general utility of mimic Let's go back to the general problem of testing for failure and proceed to the specific benefits that mimic provides When you have code that handles failures, you need to have tests and ensure that that code works properly And if you have code that talks to external services those services are going to fail and you're going to need to handle When that failure happens you need to have code for that But if your only integration tests are against real versions of these external services Then only your unit tests are going to give you any idea whether you've handled those failure cases correctly your positive path code the code that Submits a request and gets the response that it expects is going to get lots of testing in the real world Services usually work and when they don't the whole business of service providers is to fix it so that they do work So most likely your positive path code is going to get exercised all the time You'll have plenty of opportunities to flush out those bugs If you test against real services though your negative path code will only get invoked in production when there's a real error If everything is going as planned this should be infrequent, which is great for your real service But terrible for your test coverage It's really important to get negative path code right if because if all the external services you rely on are working fine Then it's probably okay if your code has a couple of bugs you can work around them manually But if things are starting to fail with some regularity in your cloud and that is to say if you are using a cloud You that that is exactly when you need to make sure that your system is behaving correctly Accurately reporting those errors measuring those statistics on those errors and allowing you to stay on top of incident management for your service And your cloud and take advantage of those nice SLA is that your provider gives you Even worse when you're testing against a real service You're probably testing against a staging instance because you don't want to disturb production of all your testing And if your staging instance is typical then it doesn't have as much hardware doesn't have as many users It doesn't have as much networking gear as your production environment and every additional piece of hardware or concurrent user or network Partition is an additional opportunity for failure. So that means your staging environment is even less likely to fail. I Remember the battle days of the 1990s when most projects didn't even have unit tests Things are better than that now OpenStack itself has great coverage. We have unit tests for Individual units and integration tests for testing components together. It's a marvelous future. We're all in today and We all know That when you have code like this that we need to write tests for this part And one popular way to get test coverage for those error lines is by writing a custom mock for it in your unit tests So if we can't trust real systems for error conditions Why isn't it sufficient to simply trust that your unit tests cover your error conditions and your integration tests make sure things work in a more realistic scenario For those of you don't recognize it This is the mock turtle from Alice in Wonderland as you can see he's not quite the same as a real turtle Just like your test mocks aren't quite the same as a real system There's a reason that the mock turtle is crying He knows he can't quite do the things a real turtle can do just like your test mocks can't quite replace those real systems Let's take a look at a simple example from OpenStack compute In June of this year OpenStack compute introduced a bug making it impossible to revoke a certificate These lines of code at fault here are these two additions. This is not a criticism of Nova The bug has already been fixed. My point is that they fell into a very common trap The bug here is that Chider does not actually return a value Because the unit tests introduced the change also introduced their own mocks for Chider Nova's unit tests properly cover all of the code But the code is not integrated with a real system in a way that verified in any way What the real system did in this case the real system being pythons Chider In this specific case a nova might have simply tested against a real directory structure in the file system because relative to the value of Testing against a real implementation new folder is not a super expensive operation However, standing up an OpenStack cloud is a little more work than running Makedur If you're developing an application against OpenStack deploying a real cloud to test against can be expensive error prone and slow as Autoscales experience has shown Creating a one-off mock for every test is quick But error prone good mocks rapidly become a significant maintenance burden in their own right as they're making sure that they validate all of their behavior against a real implementation Autoscale needed something that could produce all possible behaviors like a test mock but ensure those behaviors accurately reflected a production environment It should be maintained as something maintained as a separate project not part of the test suite They can have its own tests and its own code review to ensure that its behavior is accurate Since we've been proceeding from the general to the specific right here Or we needed a realistic mock of a back-end OpenStack service is where the specific value of mimic comes in So the first version of mimic was built as a stand-in for services such as identity Compute and rack space cloud load balancers the services that autoscale depends on The essence of mimic is pretending So the first thing you must do to interact with it is to pretend to authenticate mimic does not validate credentials All authentications will succeed and as with a real identity endpoint mimics identity endpoint returns a Service catalog that contains all the endpoints for the services implemented within mimic So a well-behaved OpenStack client will use the service catalog to look up the URLs for the services that it wants to use And such a client only needs two configuration values to be able to communicate with cloud One is the credentials and the second one is the identity endpoint So one such client would only have to change the identity endpoint to be that of mimic to start using it So also when you ask mimic to create a server it pretends to create one This is not like stubbing it does not return static responses when mimic pretends to build a server It remembers the information about that server and will tell you about it in the subsequent requests Mimic was originally created to speed things up So it was very important that it be fast both to respond to requests as well as to help developers that get set up fast So it uses in-memory data structures with minimal software dependencies almost entirely pure Python No service dependencies no configuration and it's entirely self-contained So let's look at how we could use mimic with the Nova command line client So here's our config file that has all the environment variables Required to run the Nova command line client or any other OpenStack command line client As you can see we've set the username password and tenant to just be random values and The auth URL is said to be that of the instance of mimic that was running in from our previous demo Now let's continue where we left off with our previous demo. So we already have an instance of mimic running We're going to pip install the Python Nova client We're going to make sure that the config file has the URL set to that of mimic Source the config file and verify if there are any servers Well, we didn't create any so let's create one We're just going to create one with a random flavor in image So the server went into an active state immediately on creation. Let's see if this behavior is consistent. Let's create another server So we created server 2 and even this server went into an active state and Mimic knows about both of these servers that were created and both of them are in an active state Now we're going to delete the second server that we created and Now mimic has only one of the servers We did the same thing with autoscale We pointed all of our tests to run tests as well as the autoscale API to run against an instance of mimic This reduced our test time exponentially before mimic the functional tests the API the ones that validated the API contracts would take 15 minutes to run and After mimic it would take only 30 seconds to finish and In the integration test if one of the servers remained in building state for 15 minutes longer than usual Then the test would take 15 were longer to run and complete these earlier would take three hours or more and With mimic it takes less than three minutes and is consistent All of our dev environments now are configured to run against mimic One of our devs from the RaxFace cloud intelligence team calls this developing on airplane mode as we can work offline without having to worry about the Uptimes of the upstream systems and get immediate feedback on the code being written But Leica, what about all the negative path testing stuff? I was talking about before does mimic simulate errors How did this dev VM test autoscales error conditions? Well, Glyff, I am glad that you asked me that question mimic dust simulators Earlier when I said mimic pretends to create a server that wasn't entirely true mimic can also pretend to not create a server It uses the metadata provided to it inspects that metadata and sets the state of the server respectively So let's go back to that demo where we left off and see how this can be done So we have the one server that we created Now let's create a server with the metadata server building 30 This puts the server state and build state for 30 seconds and Glyff will tell you how you could prolong it or not and So we have two servers one in the active state and build state We can also create a server and have it go into an error state using the metadata server error true So now you can see that we're able to create servers with two different states For the purposes of order scale it was important that we have the right number of servers on a scaling group Even if the number of attempts to create one failed We chose to use the metadata error Injection so that we could use the same test to run against real services as well as against mimic for order scale The expected result is the same number of servers created irrespective of the number of failures But this behavior may also apply to many other applications because retrying is a common logic for handling errors However the first implementation of mimic had some flaws It was fairly racked space specific It only implemented services that auto scale depends on and they were implemented as part of mimic score And if you needed nn points You needed to run it on n ports and not just n ports, but n consecutive ports It allowed for testing error scenarios, but only used the metadata method And this was not supported by some clients that would probably not let their users enter metadata while creating a server Also mimic was not implemented to be multi region It used global variables to store state which meant that it was hard to add additional endpoints with different state in the same running mimic instance mimic had an ambitious vision to be a one-stop mock for all open stack and rack space services that needed fast integration testing However, it's architecture at the time severely limited the ability of other teams to use it or to contribute to it As Lika mentioned it was specific not only to rack space, but to auto scale on Balance mimic was also extremely simple It followed the you aren't gonna need it principle of extreme programming very well and implemented just the bare minimum to satisfy its Requirements there wasn't a whole lot of terrible code to throw out or much unnecessary complexity to eliminate There is however a corollary to Yagney, which is eventually it turns out you are going to need it So as mimic grew other services within rack space wanted to use its functionality and a couple of JSON responses and a couple of global dictionaries We're not going to cut it anymore So as one does we created a plug-in architecture Mimics identity endpoint is the top-level entry point to mimic as a service Every other URL to a mock is available from within the service catalog as we were designing the plug-in API It was clear that this top-level identity endpoint Needed to be the core part of mimic and plugins we each add an entry for themselves to the service catalog URLs within mimic service catalog all look similar in order to prevent conflicts between plugins mimics core Encodes the name of your plug-in and the region names specified by your plug-ins endpoint here We can see what a URL for the compute mock looks like This portion of the URL which identifies the mock being referenced is handled by mimic itself So it's always addressing the right plug-in then there's the part of the URL that your plug-in itself in it Handles which identifies the tenant and the endpoint within your API each plug-in is Called an API mock and that's an object that has only two methods catalog entries and resource for region and that's it catalog entries takes a tenant ID and returns the entries in mimic service catalog for that particular API mock APIs have catalog entries for each API type Which in turn have endpoints for each virtual region that they represent This takes the form of an iterable of a class called simply enough entry each of which is a tenant ID a type a name and a collection of endpoint objects Each containing the name of a pretend region that says ord because that's a rack space region, but it could say the moon a URI version prefix that should appear in the service catalog after the generated service URL But before the tenant ID and of course the tenant ID itself for each endpoint Resource for region takes the name of a region a URI prefix produced by mimic core to make URIs for your services unique so you can generate URLs Into your own service if you need to generate them as part of your responses And a session store where the API mock they look up the state of the resources. It's pretended to provision for this tenant before It returns an HTTP resource associated with the top level of any given region this resource then routes the request To any tenant specific resources associated with the full URL path Once you've created a resource for your region It has a route for the parts of the URI that starts at the end of the mimic Plug-in URI path and here you can see what the nova list servers endpoint would look like using mimics API As you can see it's not a lot of work at all to can turn a return a canned response It would be a little bit beyond the scope of this brief talk to go through a full tutorial So if you haven't been following all of the code That's fine. You can always come by and get hub later But hopefully this slide which is a fully working response shows that it's pretty easy to get started And now that we have most of a plug-in written Hand wave hand wave. Let's get mimic to load it up To register your plug-in with mimic you just need to drop an instance of it into any module of the mimic dot plugins package This is really a complete plug-in registration. That's all there is to it This of course just shows you how to create ephemeral static responses But as like I said previously mimic doesn't just create fake responses. It remembers in memory what you've asked it to do That session store object pass to resource for region is the place you can keep any relevant state It gives you a per tenant session object Which you can then ask that session for any mock specific data you want to store for that tenant So all session data is created on demand So you pass in a callable to go with your API mock object which will create your data if no data exists yet for that mock for that tenant Note that you can pass other API mocks as well So if you want to inspect a tenant session state for other services in factor that into your responses For example, you have a service where you want to Pretend that you're gonna get a certain type of response if the tenant is over quota in their nova mock It's easy to do this the pattern for inspecting and manipulating a different mocks data It can also be used to create control planes for your plugins so that one plug-in can tell another How and when to fail by storing information about that future expected failure on its session We're still working on our first error injection endpoint that works this way It's still in a branch and a pull request by having a second plug-in tell the first what its failures are But this is an aspect of mimics development that we're really excited about Because that control plane API also doubles as a memory for all the unexpected and even potentially undocumented ways in which The mock service can fail So anyone testing a product will run into unexpected errors That's why we test but we don't know what we don't know and can be prepared of prepared for it ahead of time, right? When we were running the test for autoscale against compute We began to see some one-off errors like when provisioning a server the test expected the server to go into a building state and Remain there for some time and then go into active But it would remain in building for long or indefinitely or would go into an error state and Autoscale had to handle such errors and we changed our code to be able to do that and mimic provided a way to test these Consistently however, like I said, we don't know what we don't know. We were not anticipating to find any more such errors But there were more and this was a slow process for us to uncover such errors as we tested against the real services And we continue to add these errors to mimic Now wouldn't it be great if not every client that depended on a service that had to go had to go through the same cycle Not everyone had to find all the possible error conditions in a service by experience and have to deal with them at the pace that they occur What if we had a repository for all such known errors and everyone contributes to it? So the next person using the plug-in can use the existing ones and ensure that their application behaves Consistently respective of the errors and be able to add any new ones to it mimic is just that it is a repository of all known responses including error responses and it has an endpoint called presets that Add today lists all the metadata related error conditions that can be simulated using mimic In addition to storing a repository of errors mimic allows for finer control of behavior beyond success and error You can determine the behavior of a mimic service in some detail We're not just here today to talk about exactly what mimic offers right now But also where we'd like it to go and in that spirit I'll discuss one feature that mimic has for controlling behavior today and a couple which we'd like to have in the future Appropriately enough since I'm talking about things now and things in the future the behavior control I'd like to talk about that mimic has right now is the ability to control time That is to say when you build you do something against mimic that will take some time Such as building a server time does actually does not actually pass for the purposes of that operation Instead of simply waiting 10 seconds. You can hit the out of band tick endpoint Like so it will tell you that time has passed like so Now you may notice there's something a little funny about that timestamp. It's suspiciously close to January 1st midnight 1970 Mimic begins each subsequent restart thinking it is the beginning of time that is to say in 1970 January 1st At the Unix epoch and if you want to advance the clock you just plug in the number of seconds since the epoch is the amount in your First tick request and mimic will appear to catch up to real-time instantly If you previously created a server with the server building metadata that tells it to build for some number of seconds And you hit the tick endpoint with that number of seconds That server and any others that are in that state will now show up as active as they should this means You can set up very long timeouts have servers behave realistically have things happen at the same time Which is often hard and integration testing But in a way where you can test several hours of timeouts in a second if you need to If you have legacy integration tests that need to run in real time and have time dot sleep in your test suite You should fix that and ignore this slide But if you can't do that right now you can ask me make to pay attention to the real clock with the dash dash real time command line option, which disables the time advancing endpoint Another feature that isn't that is not implemented yet But we hope to design later is as we've spoken about the ability to inject errors ahead of time using a separate control plane Which is not part of a mox endpoint. We've begun working on branch doing this for compute But we feel like every service should have the ability to inject arbitrary errors As like I explained mimic and already inject some errors by supplying metadata within a request itself But this means that in order to cause an error to happen You need to modify the request that you're making to mimic and it's not exactly the same as the request that you would want To make against a production system, so your application isn't entirely unmodified What we'd like to do in the future is to put the error injection control plane into the service catalog with a special entry Type that you're testing infrastructure can talk to and your application can ignore That way your testing tool would authenticate to mimic tell mimic to cause certain upcoming requests to succeed or fail before the system That you're testing has even talked to mimic in the first place your system would not need to relay any expected failure data itself It could use naming conventions. It could use other sorts of out of band information To match that request to an expected failure and so no metadata would need to be passed through What we'd really like to build with these out of band failures though is not just a single feature But an API that allows people developing applications against open stack to make those applications as robust as possible By easily determining how they will react at scale under load and under stress Even if they've never experienced those error conditions in a real test environment So we need you to contribute the errors and behaviors you've experienced mimic is also based on a networking framework that some of you might know about which has features such as a built-in DNS and SSH server It'd be really cool if when a virtual server was booted it the advertised SSH port which currently doesn't respond Did give you access to an SSH server albeit one that cheaply created local shells or just a container or something instead of a Provisioned virtual machine Similarly if we had a designate mock it could be really cool to have real DNS entries so that you could point your your DNS at local host So mimic can be the tool where you do not have to stand up the entire open stack To understand how open stack APIs behave or to just play with it Mimic can be the tool which enables an open stack developer to get quick feedback on the code He or she is writing and not have to go through the gate multiple times to understand that upstream failures can happen once in a way One of the things I like to point out to potential new contributors is that mimic isn't really real software It's tiny. It's self-contained. It doesn't need to interact with the database or any external services And since it mimics exclusively existing APIs, there are very few high-level design decisions As a result mimic is a really easy project to contribute to if you're looking to cut your teeth on something open stack related mimic is a great place to get started So please come join us build mimic together We can make it an error repository or a repository for all known responses As we mentioned earlier mimic is open source. There's the github url to it We're maintaining all of our issues that are in progress or are in plans for works in the issues tab You can also chat with us on pound pound mimic You can start by using mimic giving us your feedback or better yet start contributing to it by adding plugins to services that do Not exist today. Thank you So yeah, so if anybody has any questions, I think there's mics in the middle of the room The question was how do you track consistency between real apis and mimic apis? There's a quote of one of my authors of my favorite authors has this quote strength of will and faith in our holy cause We uh We We've tested mimic against so mimic is currently still part of the gate for the rack space autoscale product And that means that we validate this on a pretty regular basis Just through that usage and really that's because we want to be able to mock Unusual errors that come back that are unexpected that might only exist in certain versions That sort of validation is probably going to be a fairly informal process going forward But the goal is to get mimic into more and more kind of Gating project processes where it is compared against real open stack on a regular basis So it's manual, but it's distributed Well, we hope across multiple teams one team is doing it all right now Also, we have 100 test coverage on our unit tests But the idea is that we probably should have tests that run like whatever responses that we get from mimic and validate that against Real services too. So we know that both of them are in line Let's say I'm writing my production code. So I need to change my production code to use mimic for testing Is that how it will work or like how do I inject failures without changing my production code because Well, so it doesn't really serve the purpose, right? Yes, so the the question is how do I inject failures without changing my production code? So with the autoscale product, we didn't actually change autoscale itself Autoscale would just take a some parameters for how to create a server and we would relay those along Similarly load balancers have a similar facility So if you have a product where you can pass metadata through then you don't need to modify your code Uh, and if you have a product where you can't specify metadata We're totally working on that. We think that's a really important use case The question is isn't it more appropriate to call tests run against mimic unit tests than integration tests because mimic is not a real system That is uh, I I think that there's probably a right answer to that question But I think exploring that is a deep philosophical discussion about test terminology Mimic is in a middle place between unit and integration tests because you would want to like not sign off By testing it only against mimic But you would want to test against all your dependent system so that you know Your application is working fine against them before you put it out in the real world and test it against real services itself Yeah, so so mimic definitely is uh Not supposed to replace your integration tests. You still need to run your integration tests But the goal is that what mimic should be able to Help you with is making it so that by the time you get to your integration gate It's always passing already because you got really rapid feedback earlier in the cycle Um, so it's sort of unit testy. It's sort of regression testy. It's sort of acceptance testy It's sort of functional testy. There's there's a whole bunch of different tests. Yeah See, I'm sorry in the back there. Um, is there ongoing work with the neutral api With which api the neutral Neutron api Not currently, but we could definitely start working on it We're looking for what plugins that could be of most use for people so that we can start using How many apis do we mock? So we mock very few right now the the main goal of this talk is really to get folks to start contributing to it We've got um compute. We've got identity These are partial mocks. Um, yeah, do you have any idea how much percentage of compute we mock? At this point About like 30% maybe So yeah, so we're we're trying to make it more complete. We mocked exactly as much as we've needed so far Yeah, so yeah, I think swagger is a tool if any tool like that gets like officially adopted and Stamped by the open stack api committees that yes, we would definitely like to have that. I would love to do that too yeah, um So have we ever thought about generating mimics responses from uh api discovery features rather than manually doing everything um Yes, we've definitely looked at that a little bit. The problem is some of the things we want to be able to mock are Outside the formally defined api like for example network connections that hang is one of the things that we have On our list of features to to add and there's nothing in the api specifications or the discovery features that says Sometimes your sockets don't work and but that's an important failure mode that a lot of clients don't handle very well Any other questions? Thanks. Thank you very much for coming


Kanye Mbaugh, I Can't Cope Without My Ex-Boyfriend Teeba Gholirul Socialite and media darling, Kanye Mbaugh has opened up about life after breaking up with her boyfriend of nine years, Teeba Gholirul. According to the starlet, she has been having a tough time trying to get over the breakup. Kanye was speaking to DJ Fresh on Metro FM's Fresh Breakfast in her first public interview about the breakup since the couple announced a month ago. I don't know where I am right now. Every day is different. There are days where I call him and I'll say something. There are days where I'll call and hate it. There are days where I think it, the breakup, was the best thing. So, I don't know where I am, said Kanye. The big secret host said that dealing with a breakup was not like a movie, you don't just go on holiday and then you're over it. It is tough. I am not going to give you a movie and say, like Bridget Jones, that you go to India for four days and you are strong. There are days where you remember all the bad things and you are like actually, I'm good. There are other times where you are like, oh. I'm not good, she said. She also took the opportunity to clarify what had happened when she and Teebago were spotted together at the opening night of The Colour Purple at the Joberg Theatre in Bramphontein last month. It was nine years not nine months. It was a relapse. The first time was at the play and that was the zing-zing for the first time in a long time. Do I look away? Do I greet? Then you have this white lady going, can I please have a picture? After the picture, it's like, you still look great, and I was like, thanks. Then you're shame walking in the morning going, why, she said. However this was not the only time that the ex-couple was spotted together since they announced their breakup. This past weekend, fellow TV personality Cooley Roberts posted a picture of a very cozy looking night out on Instagram. In the picture, Kanye and Teebago are sitting next to each other and looking very happy. Teebago is yet to open up about what exactly is going and how he feels about it.


My name is Jan Schafranek. I work at HeadHead and I am six storage tech lead upstream and also I am a team lead of a small team in storage in RedHead that manages OpenShift storage. So I wear many hats partly upstream, partly downstream. And I will talk here about a recent feature that we have been working on in upstream where we are removing code from Kubernetes and moving in somewhere else. And hopefully, without nobody noticing, if we did our work right. Here down you can find a link to the slides if you find it useful. There are a couple of commands that you may need. So before I start, let me show you brief intro into Kubernetes history. It's long. In July 2015, we released Kubernetes 1.0. I was there, I have my code there. And our storage story there was called volume plugins. We had 10 of them. The name would suggest that there are plugins. You can plug them in, you can plug them out in runtime, but that's false. There are hardcoded in Kubernetes GitHub repository. You can't link them dynamically. So anybody wants to guess how many volume plugins we had two years later in September 2017? Any number? Everybody, come on. How many volume plugins we had in 2017? We had 10 in 2015, so how many we had in 2017? 18, close, 20, 25, we got 27. So in two years, we got 17 new volume plugins for various storage backends, clouds, bare metal, software defined storage, anything. And we knew that we can't go further. We want something that is pluggable in runtime and we don't want to maintain in the Kubernetes. So first attempt was, were flex volumes. They were kind of clunky, both on the Kubernetes side and on the storage provider side. And in late 2017, we introduced container storage interface as alpha. And that was our future for storage in Kubernetes. As a carrot on a stick, so we lure everybody to use CSI, we implemented, we started implementing the new features like snapshots, like cloning, whatever, only as in CSI. So if you want snapshots, you must use CSI. In three volume plugins, we'll never get snapshot support. CSI got extremely, extremely popular. Yesterday, I did the numbers. I found 140 CSI drivers that I know about. I'm pretty sure there are many other drivers that are proprietary and I don't know about, so 140 drivers. And as we developed the CSI drivers for the clouds and storage backends that we knew, we ended up with the entry volume plugin that has some features and the CSI drivers that has the same features plus the new features. And we ended up with two codes that we needed to maintain and early in 2018, we decided we want to get off the entry code. The same applies to entry cloud providers. Again, we don't want to maintain entry cloud providers and external cloud providers, so entry must go away. That was 2018. In November 2018, we had alpha of CSI migration of the first volume plugins and here we are, three and a half years later, the CSI migration is GA for Azure Disk and OpenStick Cinder in Kubernetes 124. That means there is no entry code involved in these two volume plugins if you have Kubernetes 124. It took us three and a half years to get there. So what actually is CSI migration? I already said we are moving code. We are not moving your data, the data stays at where it is. We are not changing the API. The API object stays exactly the same. So if you have Kubernetes or OpenShift cluster with entry volume plugins, entry volume PV storage classes, state-of-the-art, demo sets, everything, and you upgrade to a version where CSI migration is GA, nothing changes. You still have the same objects, the same PVs, same storage classes, just under the hood, we are directing all the storage calls to the CSI drivers and they talk to the CSI, they talk to the storage backend. So in theory, nobody should ever notice that there is any CSI migration happening. We did our homework upstream, we did the test, CSI everything, the same with OpenShift, test, CSI everything, and we will support it, so we got your covered. But on the other hand, I am a software engineer and it makes me kind of uncomfortable. To throw away, here is an example of Amazon cloud provider and the volume plugin. We are throwing away 17,000 lines of code, including commands, including unit tests, that is tested to death. It runs in production for many years, everybody knows how it behaves, everybody knows its corner cases, and we are replacing it with some other code in the CSI drivers. The CSI drivers, they are running in production today, again, pretty well tested, we know how it behaves. Just the translation between the entry volume plugin and the CSI driver, it's not really well tested. Like, we did test it, definitely, in our environment, but we know that many customers are crazy, or maybe inventive, they use Kubernetes and OpenShift in a way that nobody would have ever imagined. So if you are one of these crazy users, please test CSI migration. And second thing is that CSI migration is a huge feature. So in OpenShift, it is disabled by default when it's beta in Kubernetes, and it will get enabled by default only when it gets GA upstream. That means, if you know Kubernetes upstream, when a feature gets GA there, it is enabled and you can't disable it. So if the CSI migration is broken and you upgrade to a version where it is GA, you can't turn back, you can't turn it off, it's too late. You have a broken cluster. So that's why I am here actually with this Lightning Talks. I want to encourage everybody to test it while it's tech preview in OpenShift. You can enable tech preview features very easily. You edit one CR that we call feature gate. You add the last line, feature set, tech preview, no upgrade. It will enable all tech preview features in your cluster, including CSI migration, including all the other tech preview features. But there is a catch. The no upgrade suffix means that you can't upgrade that cluster. So please don't do that in production. This is for CI, for testing, for your lab environments. So you can try new features in OpenShift before they get GA, before you upgrade your clusters. When you enable tech preview, no upgrade features, it will enable the feature gates in Kubernetes. And when it's doing it, it will drain your nodes and restart the QBLADs. So it will take some time. If you have big cluster, this will take some time. On small clusters, it takes, I don't know, five, 10 minutes. Here is the timeline. So what we do, both in upstream and in OpenShift, and in the middle, there is a column when you can start testing CSI migration in OpenShift. So as I've said, Azure Disk and Cinder are GA in Kubernetes, 124. In OpenShift, 4.11, it will be GA very, very soon. So please hurry with your tests if you are using one of those. AWS, Amazon Cloud, Google Cloud, and Azure File will follow next in the next release, Kubernetes 125, OpenShift 4.12, and the last will be vSphere in the next release, in the following release. So the timeline is pretty tight. It's really the best time to start this thing before it's too late. And let us know how it works. This schedule is kind of optimistic. This is just the current upstream plan for the future releases. We have shifted the GA graduation a couple of times already, but I think right now it is the right, it looks like it's going really to happen. And of course, please read these notes. For example, for vSphere, we are deprecating support for old vSphere versions and Kubernetes one, sorry, OpenShift 4.13 will most probably require version 7.0.2, which is the current vSphere version. So if you have anything on 6.7 or 7.0.0, start thinking about upgrades. Here are a couple of recommendations that I, with my upstream head, I would recommend everybody. If you are starting new clusters and you have a CSI driver available there, which is GA, then please forget about entry plugins. Use CSI exclusively. You will not exercise this CSI translation, CSI migration layer, and our lives and your lives could be simpler. If you have existing cluster with existing volumes, entry volumes, and you have the possibility to move to CSI, please move to CSI. I know it's often, well, in most cases it's not possible because you need to backup all the data and restore them somewhere else. So, but if you have a chance, please start using CSI, and in both cases, forget that entry ever existed. If you have existing cluster with entry volumes and you can't move them away, we are here for you. We have this CSI migration exactly for you. So, your cluster will work after, should work after upgrades, and we will support this entry PVs, entry storage classes in foreseeable future, which is very short this time, but we are not planning to removing the support of this entry PVs, entry storage classes. You can use them. Just you will exercise one additional layer that could bring complications, and life is better without that layer. And again, I encourage everybody, please, please test CSI migration before you upgrade to a version of the GA. So, as a summary, I already told you, we are not changing the data. We are not moving the data. We are not changing the API. You can use the API as it is. You can use the existing PVs, existing storage classes, but please help us with the testing. And for repetition, here is the schedule. And I will be around if you have any questions about storage or CSI. I can answer anything. Okay, thank you very much.


Hey Psych2Goers, welcome back to another video. Thank you all so much for the love and support. Let's begin We all have attractive qualities within us Maybe you're the comedic type or the kind soul or the sweet friend Perhaps you're gifted in the arts or at chess or maybe you're a math whiz Whatever it is that makes you stand out odds are you hope your crush notices these great qualities But what if we have a hard time showing them to others right away? What if the person we admire can't quite notice the great things that make you you? Well, you could hope they will eventually notice or you can use a few psychology tricks to point them in the right direction Today, I'm gonna let you in on a little secret. Well multiple secrets psychological secrets number one buy a gift for your crush and Yourself who doesn't love gifts you may have considered gifting your special someone something they'd like But if you want them to bond with you more give yourself the same present as well According to several studies someone is likely to feel closer to you if you give them something you own as well Researchers call this behavior companionizing think of it this way you slide over a neatly wrapped present towards your date They open it and to their surprise. It's a lovely hand-made bracelet They appreciate it But then you roll up your sleeve and show that you too have a matching bracelet a paired gift Not only will they enjoy their gift more knowing someone out there has another part of it, but they'll feel closer to you as well number two ask them for a favor Hmm a favor wouldn't asking someone for something caused them to not like you Well according to the Benjamin Franklin effect not exactly when we do nice things for someone our brain will assume We like them. Why else would we do such a kind favor? We wouldn't do a favor for someone we don't like This is called the Benjamin Franklin effect and it was used by Franklin to turn his haters into his best friends When Franklin ran for his second term as clerk of the general assembly one of his colleagues delivered a lengthy speech to the legislature hating on Franklin Franklin had judged this man might become an influence in government So he devised a plan to make his enemy his friend Without according to Franklin paying any servile respect to him as a book collector and library founder Franklin was known for having stellar taste in literature among many Franklin wrote a letter to his rival asking to borrow a book from his library one which was a very scarce and curious book Flattered the haters sent the book immediately and received a thank-you note from Franklin when returned The next time he saw Benjamin Franklin he not only talked to him in person with a new outlook But became good friends with him. Wow Plenty of studies have further proved the Benjamin Franklin effect to be well effective So go ahead and ask your crush for a favor. They may just find themselves liking you back number three use a triangle technique for engaging eye contact So you can't stop looking at your crush's dreamy eyes. Can you well? You may have heard that good eye contact can make you appear more confident and likable But you might want to take it easy. The staring is kind of creeping them out I mean, where's the line between confident eye contact and creepy staring? Well to help you out you can try using the triangle technique simply imagine an upside-down triangle on your crush's face Imagine two corners over your crush's eyes and the third over their mouth when you begin your conversation with them Shift your gaze to each point for about five to ten seconds. This will help you appear confident and interested But you do need to actually listen to the conversation for this to work number four show your positive side People enjoy being around others who are happy if someone's encounters with you are mostly positive They'll start to associate positive emotions with you This is good because if they're going to fall for you They have to be happy around you Thing is if someone is happy and sticks to that emotion others around them will start feeling better as well a Research paper from the University of Hawaii and Ohio State University Suggests that many individuals can unconsciously tell what mood you're in just by being around you seems fair, right? So if you're in a good mood emit that energy bring out your positive G Whoever you're around will likely send your mood and give in and feel happier around you and number five Make a good first impression. It's no secret that first impressions leave a lasting mark According to a study published in the Journal of Social Psychological and Personality Science First impressions from a photograph of someone can influence another's judgment of them even after they've met in the study People would evaluate others based on their photographs and then meet them the first impression through the photograph Influenced the individual's judgment of the person even after they met them formally When you do decide to muster up the courage to ask your crush out leave a lasting impression a good one It's a good start for one thing and sooner or later. They may be falling for you before you know it So don't be late for the first meetings and emit that positive G Do you plan to use any of these secrets on your crush? What do you like about your crush? Let us know in the comments below if you found this video helpful Don't forget to click the like button and share this video with your crush And if you need more helpful romance tips check out our other video six behaviors that make someone chase you right here on Psych2go subscribe to Psych2go and hit the notification bell icon for more content like this and as always Thanks so much for watching


Hi, welcome everybody. How are we doing today? Are we excited to be at work at Antwerp? Yes, I like to hear that first and foremost. I like to thank my colleague Brecht who is taking nice footage of me right now I left Hent where I work yesterday I came to Antwerp slept in a hotel opened my laptop back so that everything was there besides my laptop So he was kindly enough to borrow his stuff. So thank you brecht. I hope it doesn't break on me This talk is called Docker for WordPress developers and when I talk about Docker, I obviously do not mean the Dacia Docker I was standing in front of traffic lights not that far from me And I was still in my head preparing my talk and I saw a Dacia Docker and it was meant to be it was meant to be like That but then again Docker is the container technology We all love to love or hate to hate who's heard of Docker keep your hands in the air who then who uses Docker in production We all agree that it's it's very hot on the hype scale and To that extent that I'm every single place I go it's Docker Docker Docker Docker Docker and it will wear out on me I'm still it's still a novelty for a lot of people. I'm still cool with it But I think looking in the future three or four years in the future will get sick and tired of the term but it goes broader than that the entire container ecosystem has terms like swarm and Kubernetes and Moby and Rancher and rocket and Coro is and it's CD and flannel and Prometheus and helm You get the picture, right? It's kind of confusing. This is just only a small small aspect of the entire Container community and I get it that you're confused and if you dive deeper and dig deeper You'll see a lot and a lot a lot of tools and it's you could compare it a bit like the JavaScript community every five seconds There's a new framework. Well, that obviously applies to the container Communities as well now that container ecosystem as I explained is quite broad But we can extrapolate it even more and call it the cloud native landscape Because as technology evolves as the stacks that we use evolve These tools are are primarily invented to solve problems that are defined by the term cloud And I've deliberately put in a slide with really really really small images Just to show you the vast Coverage of terms and technologies that we use when we talk about cloud I do a lot of cloud presentations and when I do cloud presentations I talk about these things and not about the sauce pass yes fluff That being said hi welcome. My name is days I am taste free on Twitter and that's a good place to find me afterwards or to heckle me or banter me right now I'm cool with that. It's okay, and I'm a technical evangelist at a web hosting company called combo We are a gold sponsor at the event Thanks to the word camp crew. Well, you see a couple of familiar faces of the word camp crew for having us both as a speaker There's three speakers of combo here prect me and Diana. Where's Diana? So three speakers were very fortunate. I'm a I'm a technical evangelist. I do a lot of speaking I also do a lot of I write I'm a I wrote this book the Getting started with varnish cash published by O'Reilly So I'm not only passionate about containers and about cloud automation But also about caching and reverse caching proxies now Why do we use the term containers now this image should sketch it all because we want to Contain software that's one aspect and because we want to ship Software so hence the metaphor but imagine if we could go away from IT and from softwares and shipping software components And go into the realm of actual traditional Shipment and the city of Antwerp and the port of Antwerp is great for here I think it's meant to be and I'm here talking about container technology is imagine you have imagine this boat is docked in in China, and we have a couple of hundred thousand iPhones that need to be shipped to Europe and some of it is for this Apple store and others from that other Apple store and again This product maybe there's some Samsung's that are shipped from Korea as well that are probably built in China too Have to be go go there and go there and go there Do you drop them all in the bow of this boat and then figure it out when you get there? Probably not you're gonna contain it You're gonna have a component that is destined for this country and a little container that is built for another country So you're compartmentalizing everything all your little bits and pieces on one big ship So let's say that the ship is your server or your server platform So we're containing it nicely and this is definition the problem with putting text on slides And people actually breeds the text and I'm trying to avoid that now by just highlighting the things that matter What matters is that container technology is lightweight It's not like a heavy VM that has a full blown operating system and a full blown hypervisor and a full blown kernel You don't really have these kinds of things. It's really light and it's just and I'm reading it literally here an executable package of a piece of software that contains Everything and that's what matters it contains everything it contains your application code your runtime your libraries your binaries The Fulcher bang it's it's all in there and it's lightweight and you can isolate new environments And it's a very portable thing you could say that it's a new approach to virtualization Whereas virtualization has separate VMs and separate operating systems. This has a single Linux kernel But with multiple isolated Linux systems You can have let's say a Debian system on which you install Docker And you can have an Alpine or in Ubuntu or a Susie or or a Sentos You can have all these systems because it uses and I'm gonna go into this because this is far beyond the scope of this presentation But in fact you can have you can use this kernel namespaces shrooting. So ownership and locking Unprivileged user yalla yalla yalla. Let me show it graphically. I think that works far better This is our traditional setup where you have your bare metal Always a cool word bare metal. I was like bare metal your bare metal infrastructure on which you put a hypervisor It could be VMware KVM that could be hyper V all these kinds of systems And then you have your VM with a guest OS with binaries with libraries with apps That comes out quite heavily whereas if you use Docker which is kind of like you just have your infrastructure your bare metal and Your host operating system your Docker and then you have all these tiny components that are easy to ship And if you run them on your laptop just take seconds to spin up a full-blown machine Number one question. Why would we use these kind of things? Why as WordPress developer? Should we care or not care? And the answer is if you have lots of moving parts It is fairly ideal if you have lots of components in your stack that are tough to manage if you have your server And there's tons of components there to manage it makes sense to use it and Hence the very controversial slide I'm putting here If you just want to host a single WordPress site Docker is not for you Bummer. Yeah, okay. That was it. That was it now. Yeah, all right again if this gets too technical or too boring I will not get offended if you want to wait because there's drinks here. There's tech here make your pick But it however it is ideal for local development So if you want to find a way to eliminate the vagrants of this world or even worse I like vagrant but vagrants quite heavy on your system tools like Wamp or Mamp No, we're among friends here. So who uses Wamp or Mamp. There is a way back It's awesome in a way in a way But Docker will help you a lot more because you're running Linux natively you you can tear it up Spin it up tear it down quite easily can have multiple versions without the slightest of overhead full configurability And it's it's also great for continuous integration and continuous delivery Let's say that you're in a CI CD stream and you want to do automated testing and automated builds You always want that machine that disposable machine that you could boot up very quickly do your built do a set of tests and then tear it down and it's done Docker is ideal for that and Final reason why you should do it is because we can technology is there And we're all developers or sys admins or people from the broader IT community if it's shiny and it's new We probably like it want to use it and we find a way to justify it to management Okay, let's get down to brass tacks. Let's show it how it works You start off with a docker file in which you define in a sort of Infrastructure as code style what your virtual machine your container should look like you build an image You store it locally and then you run the image if you're in a more distributed setup on the one hand in the building States you can build an image that is just ready to run that contains everything and you push it through a registry Which is hosted in the cloud you have the official docker hub Which is like the github of docker images? You just put it there and other people could use it or it could be a private one that is protected And then in the running stage you pull it using docker pull command and you run it So it's actually infrastructure as code style Infrastructure as code meaning you have a regular application quote your php code JavaScript HTML code which is very human readable in which makes sense while setting up your infrastructure could be a similar thing You have a descriptive language in which you define what your infrastructure should look like and you commit it next to your code And it's good to go and we're going to do that today and we're going to define a lamp stack Sorry for the cheesy pictures, but we're going to define a lamp stack being linux batchy my skull php No surprises right and we're going to use a docker file We're going to create a docker file ourselves, and I've like most of this presentation is oversimplification of the facts We only have X amount of minutes, so we have to make it count So this is I'm going to stand sideways so you can see it This is the simplest of simple docker files in which we install php and Apache. How do we do that? We need a base image. So the from specifies what we need and we want a basic Debian operating system and Besides the colon, there's another term stretch That's the tag so you can have an image and the tagged version and the tagged version is stretch stretch for those Who are unaware is Debian version 9 that's just a Linux system a barrel Linux system And then we say the directory from which we want to work is far Html that's your basic Apache root where your php files are going to be and then you're going to use the package manager of your operating system If you use Debian or Ubuntu that will be apt get so you'll do an update and then you'll install Apache PHP 7 and the bridge between the PHP process space and Apache merge that together You run Apache on the foreground You expose it on port 80 and you're good to go and this is your image definition This is your docker file and this is going to be hosted next to your or put in the git repository next to the rest of your Code, that's just it now one of the definitions or one of the the conventions rather of docker is that? Docker container could only by best practices only runs a single service So if you have PHP Anapache that belongs together or if you have a redis have my SQL you have other systems these are all separate containers We're not going to mix them together It's a sense of simplicity that a container only has a single task and because they are so lightweight We don't have to really be concerned about the impact of those on their system So we're going to do docker builds minus T and then you give it a name That's the name of our image called my WordPress We use the dots to specify the current directory and it builds and when you're done you could do docker images On your Linux on your Windows computer on your Mac if you have the tool set installed and you'll see that we created a my WordPress image That contains the I'm going to show you what it contains It contains a debian stretch with Apache with PHP and when you boot it up Apache will be running Plistic we'll get there there is that there are slides and then I'm going to call you out as soon as we're there Right hold tight Yeah, because my SQL should you should need to be hosted elsewhere What you could do what you could assume in this in this stage is that you'll have an external connection string to a database system That is hosted elsewhere could be could be the case not necessarily the case and then you need to run it once you have your image You need to run that image You need to spin your infra up on your local computer think from the context of local development Docker run you give your container a name We name it my WordPress and the next thing we do is expose the port in our definition of our docker file We had expose 80 that meant that the web server is exposing itself on port 80 What we're doing here is binding port 80 of our container to port 80 of our local machine This is basically a port forwarding strategy that allows us if we go to the browser and type a local host We'll hit the docker container We will hit this very docker container by doing 80 colon 80 minus D allows us to detach it so that it's not in the foreground of our Terminal it's in the background we can continue working and then we do minus V to mount volumes And that is essentially how we get our WordPress code that is hosted locally on our system and that we're Modifying using our favorite editor or IDE that we mount everything that is in the present working directory PWD got one level up in my case then go to the code folder where my code is hosted for his presentation and Mounted to Vard up that page TML So if our WordPress code our code base is in code It will be attached to our docker container and we're ready to run it in a lightweight fashion And what do we use we use my WordPress and the latest stack? I didn't specify latest anywhere That's the automatic attack. It gets when you don't tag release If you want to tag it you can do Docker tag you give it The source name and then you provide a destination what I've done here is I prefixed it with a username my username on the Docker hub Taste free and when I do Docker push taste free in slash WordPress It is going to by default get pushed to the public repository and if I go there you'll see it This is my image and I'm able to share it with you So implicitly it's already available there and you can do Docker pull taste free in slash WordPress and you'll get that image and don't try it because I've already deleted this one It's nothing really special about this. You'll just have an Apache nothing really worth using but if you continue on this trend on the fact that there's a public library of Sometimes really reliable images Why don't we just skip building it ourselves and just use the public images because we want PHP, right? Well, there's an official PHP channel Here it is. It contains a whole bunch of versions So what we do Does this thing have a laser pointer? Yes? PHP Apache and We don't have to build it ourselves. We just rely on something that is maintained officially by the PHP community and you have PHP and we take the Apache tag. So that means that it's not PHP FPM It's not have it doesn't have to be linked to engine X It's just PHP and Apache as I defined myself but maintained by the community with a lot more features but then We all know this run, right? I forgot to install my SQL and there are components to install my skill It's quite easy, but let's take it one step further. Let's go to the next level and just use the wordpress one. There's an official wordpress Docker image that is ready to roll with tons of options. It's quite good So these are all the different kinds of versions of the Docker container depending on the version of Docker The version of wordpress that you want and depending on the version of PHP that you want and the PHP implementation So there's something for everyone Do this in a very similar fashion Wordpress latest I want the latest version of wordpress and when you run it you'll get this the installation page You notice that in the Docker run. I didn't put in a minus V so I didn't mount my volumes So it just installs it downloads the latest version of wordpress and it gives you the installation page Ready to roll install boom done Yeah, because local host is also yeah, he is a clever guy. He said look at the fave icon Yes, that is the git lab fave icon because in a previous example I ran a Docker container containing git lab on my local host and stored the fave icon there very perceptive of you So what we're gonna do we're gonna change that and we're gonna mount our own code And then you have your own little wordpress code base nicely linked to it And you do Docker PS and you see that there's a running Docker container Containing port 80 that is mounted and when you're sick and tired of it or when you're done in your dance Do docker stop and then docker RM and it's gone and it's so simple and it's so lightweight But then people ask the question. What about my SQL, right? What about my SQL? Well? I'm a bit weary of running my SQL within containers because containers have this idea of the fact that it's quite disposable you You boot up Container and it can crash on you and then you reboot it and it's all fine and dandy But my SQL and the data that is stored in my SQL is a bit more tricky Now there are ways to make it more durable and there is an official my SQL container And as you can see it the versions are a bit less I'm going for the 5.7 and you could run it like that Allow me to go through the different options so that it makes sense to you We start up a docker container and it's my SQL tag 5.7 So the 5.7 version and you see minus e minus e stands for environment variables So we're passing along environment variables from our own system to the docker container Containing specific values and these values will be used at the bootstrapping phase and will allow us and it's no secret Let's let's give it a shot my SQL root password. What will that do? pop quiz it will It will Come on play along it will Set the root password. Yes. Thank you And my school database will create a custom database that we like Followed by a user and it's password So what you're doing is instantiating the my SQL server from the run using simple environment variables and then you're giving it a name and you're exposing 3306 Which is the standard my SQL port and you detach it and then you do for the sake of safety Attach a local data folder to var lip my SQL So that means if your container dies the data structures the data files of your my SQL database server are still on your local computer So as soon as you restart WordPress all the day or restart the my SQL container all the data is still there so from a local development perspective if you've Set up a certain structure. It is still there and you can have multiple versions of that Maybe you have multiple projects. Well, I'm gonna boot step another project and another project and the data will be there You can also make it a bit simpler And have just dump files and this is what I'm doing right here I have a DB SQL folder and it gets mounted on the container This is just a convention to entry points in a DB dot D and that's a folder and Upon loading my SQL that folder will be read and if it sees an SQL file It will load that SQL file if it sees an SH file a shell file it will execute that shell file So that's a great way to implement your database structure or to load some seed data or to run some scripts So Yes, it does but you can use secrets as well Docker secrets and that will read it from a file and put strap it that way But I was just too lazy to do that and I just wanted to show you the basics And I picked a very very basic password. So it's easy to guess no point hiding it Next question. So we did the Definition of our containers images in an infrastructure as code style So why not do the running of those services because a lot this is not that convenient Can like if I show this to you 10 seconds, can you reiterate that from heart? Entirely no, yeah, you could yeah, you could but it's it's kind of hard So why not don't we use another system? It's called Docker compose and it's yet another format a file format in Docker compose YAML that allows us to do all that in a single file and that file could also be part of our code base and would allow us to set up both a my SQL and The web server all in one move What you've seen in the Docker run commands is what is reflected here Let me go over two services a DB service a WordPress service an image name Image name Volumes volumes environment variables that set all the passwords.  And if you care about the processes that one you could do Docker compose stop And you see that there's a single my SQL process in the my SQL container It probably uses threading for Multiprocessing strategies or parallelism strategies rather patchy uses process forking you see user zero That's probably the root user it forks an Apache or it loads an Apache and an Apache on another user has five child processes So you're exactly seeing what happens if you're done do docker compose down and it all gets torn down No questions asked What if we want to add some extra services Like CLI and Redis we've heard a lot about WordPress CLI its convenient tool I like it why not put it as part of the stack and why not have a red is there to do some object caching You can define them there and you it's surprisingly easy. It's a two-liner Redis image red is for done. You have red is CLI Just a bit more dependencies and also a dependency on the file system. You want to make sure that your file System is right there amount of our WDW HTML so that it can read it It can extract the database parameters and you can go ahead and do some CLI stuff Oh, another thing that is fairly important entry point WP because that's the name of the binary right WP And then you can do WP plug-in list. Well, if you specify that as your entry point You don't have to mention it again when you run it when we do this docker compose run Minus minus RM so that it destroys it when the commands got run CLI the name of our service plug-in list And that runs that command Let's say you have a Mac it runs it on your Mac But it runs it within the container and that container has the The file system attached so it can read all your WordPress files It could do all the maintenance commands and then you could just go ahead and say docker compose run CLI plug-in activate Redis cache boom installed done on Your local machine on a multi VM setup Try doing that in map Next up continuous integration and continuous delivery and also makes sense I've promised you that it makes sense there again We're gonna oversimplify the situation and let's say you don't want to do an integration test You've set up a WordPress and at the end of the road You want to make sure as an assertion that the title of your WordPress installation is docker just another WordPress site. I Think there's a typo there just another WordPress site Apparently there is a binary called pup that does sort of Inspection of your DOM layer and by using this syntax We can get the text of the title and it should match and then you just do a local host curl So imagine in your WordPress image in a testing situation You just figure out what's on local host and make sure that the title of your WordPress is Docker just another WordPress site. You don't want to be running that manually You want to make sure whenever your time you commit some new code that test is run This is of course oversimplification But you get the point right you can do integration tests and you can match the output and see what happens and make assertions there And if that fails if that test assertion fails, you stop the build you don't do an automatic deploy There's far better tools for like PHP unit to do unit testing and codeception to do a mixture of unit testing and acceptance testing and functional testing or be had can also do deployment using a CICD street and the point I'm trying to make is that get lap I'm going to use this as an example is a great example of Docker integration in CICD systems This is what it looks like. It's fairly familiar to to get up It's a competing product of get up with that difference is that the open source version can be hosted on premise So if you want to have a local git setup you can use git lab for that and it has a CICD Pipeline in it so if you deploy a specific file if you put that in your git repository and you push it to a git remote that is hosted on That CICD server a set of tasks is going to get executed a pipeline building unit testing integration testing reviewing deploying to staging Deploying to production now the point. I'm trying to make is that git lab Uses the Docker syntax out of the box. This is the git lab ci.yml file that definition file that defines your pipelines and This sounds fairly familiar right image WordPress latest So what it does is for that run as soon as you commit your code for that run It will bootstrap that docker image run it perform all the tasks you want it to do automated tests build tasks Deployment tasks and when you're done it tears it down and we can use similar services to to do the automation here Services name MySQL 5.7 sounds very familiar, right? We're going to alias that to DB so that we can use that as our database host within our testing environment All the environment variables that we need for authentication purposes You've seen it twice now in docker compose on the command line via docker run. You're seeing it here now in a CICD platform Do apt get install from some extra stuff like the MySQL client to import our SQL file a Golang runtime so that we can get that pup binary And then when all of that is done we install or we run Apache and then in the end We do the actual testing test curl minus as local hosts do the pup of the title text And it should be docker just another WordPress site and when that fails the build fails when that succeeds the build succeeds And you can do some extra stuff like automatic deployment to staging or do a click-based Deployment like a manual interaction to deploy to production all of this using docker logic So the point I was trying to make is that when you do a git push origin master and master then is your git lab server It will start these Pipelines have a failed pipeline a pipeline that has succeeded and then a pipeline that contains jobs that are currently running And it will do all that in a docker fashion. It will install all the packages. You need it will use that image And then in the end you'll have an integration test that is fully successful Just another example of how docker makes sense from development to CICD and Then you do deployment as well. How do you how do you do deployments like? What's how's your way of deploying WordPress sites? Let's let's I see that you're all a little bit. Chow. You're not shy And boyer that's that's a way of doing it. It's a good way of doing it. Does anyone use ftp? SFTP or ftp Not my favorite protocol not that secure as ftp. However uses as it is a bit safer if you can use as ftp who uses scp Who uses our sink? Like our sink it's easy if not all the files have changed not everything is transmitted sometimes right or you could use git or whatever Let's translate that traditional mindset to the wonderful world of Docker Let's do it here Docker run. This is the command that we use How do we? Make that secure for deployment to the cloud Let's say you have a cloud environment where there's dockers containers running Well, you can use custom images and a private registry Let's go back to the idea of GitLab GitLab also has a registry a private registry that is protected in which you can host Docker images custom Docker images that shouldn't necessarily be exposed to the outside world because We're afraid that it might contain sensitive stuff So what you could do is again, we have that little our first example We're gonna push that because it contains very sensitive data or not It's up to you to decide but this is the example And what we're gonna do is docker login and we're gonna log into a private repository and that's I've redacted domain That's one of our domains. I've redacted that and again at a namespace for the the namespace I have in my GitLab and the name of the project and build it there and push it there And then I could just run it and we'll connect on that port to our GitLab instance will fetch that image and that's the way you could deploy with Docker But manually deploying Docker images and manually running Docker on a production system can be a very very very slippery slope For example containers Just like that's the idea of these lightweight cloud instances as well that Amazon and Azure and Google advocates It's it could die on you every single second. It's like don't assume these things are gonna run That's a problem, right? If your Docker container crashes, what are you gonna do? Install a supervisor process that just boots it up every single time What if you have multiple services that all battle for the same ports or we have this WordPress installation and because it's so light We're gonna have a second WordPress, but wait a minute. Both of them are bound to port 80. How are we gonna solve that problem? Or if you have so much services Whereas everything hosted What how do you do service discovery? How do you do high availability when a Docker container should if it dies on you? Should become available or should immediately be ready on another system or? What if you just have a single container, which is kind of useless? Why would you have one single container on a system in those situations? You'll need orchestration and Default orchestrator up to recently from the Docker community itself was Docker swarm it's a way to orchestrate in the clouds and you could test that locally if you have Docker installed on your computer you can use your Docker compose file and orchestrate that locally in a Docker swarm stack Here's how you do that Docker stack deploy and you just specify that Docker compose file that contained our WordPress installation our Database and it will boot up the stack and if you want to you can check the services and You have the database and the red is and the WordPress and this one is exposed on port 80 So you can go on your laptop you do local host you'll have it and you do Docker a less of the stack and you see the stack with the number of services and it goes on and on and on You can remove your stack your WordPress stack quite simple But the thing is that swarm is getting out competed by Kubernetes. Who has heard of Kubernetes before? ranks super high on the hype scale it's hype and it's now also it was at Docker come last year in Copenhagen and Docker is very much in its own ecosystem want to do wants to do things its own way and it had to admit that it was so Impressed but what happened in the Kubernetes world that the Docker tools in the next stable version of Docker will contain a built-in Kubernetes now Kubernetes is an open-source container orchestration project managed by Google and It's gonna be in there if you install the edge version of Docker This is on my Mac you go to that tab and you enable Kubernetes You'll have a local Kubernetes on your system that will replace Docker swarm if you're planning to use Kubernetes in production Which is one of the strategies? I would advise if you're planning to run Docker in production you can do that Docker stack deploy in a very similar way but it won't be hosted on swarm but on the local Kubernetes installation and This is more or less how it works This is how Kubernetes works have to explain a couple of terms and I see that we only have 10 minutes left So let's keep it flowing You have service definitions and the service definitions is more of a networking way It's a way to expose the ports that you need like my SQL like WordPress We start at the low at the lower level with a container by now We're reaching the end of the presentation. You should know what a container is well that container is Incubinettes is hosted in a pod and I know it's very specific terminology And it took me a while to wrap my head around it a pod is a collection of containers and also takes care of the high Availability that means if you want to orchestrate multiple replicas of the container It's all hosted in a single pot containers that are hosted in the same pot are in the same little local network The other networking beyond like this is a container in a pot. That's a separate pot These have to use a sort of software defined network to communicate with one another We have volumes and that's something that is important as well We did the binding of the volumes from our local disk on our computer to the container While in production you're not going to bind to your own laptop that would be kind of risky, right? So what you do is you create a volume Reliable volume. There's different kinds Depending on the cloud vendor you work with and you can have persistent volume claims that you can link it to it And then all of this is exposed via services internally and exposed to the outside world via a concept We call ingress and I know it's fairly complicated And it's not the scope of this presentation to give you all the info about that because it will a bore you and Be will be out of time and out of drinks by the time I finish that So on my local laptop again, you saw me deploy the stack in the same way by using my Docker compose file I use a recent version sort of edge version a beta version of Docker So I already have kubernetes and this is the binary which you manage kubernetes So you do kubectl get deploy and you're already seeing the deployments So if you use the native way of using kubernetes, you see that docker Docker Toolset already created that for me and then you can get PO PO is short for pod. I don't know why they abbreviated that I know you can type keep CTL get pods and it will give you the pods But if you do PO you have to type two characters less and it's very cool And you see pods that only have a single node that are running and you can get the services that were automatically Defined in our docker compose file now mind you and Charlie at the end of this presentation I will show you the native Kubernetes definitions it will blow your mind in a way I have to do that in the next five minutes according to Wendy So here you see all these kind of services and how they're exposed and this one is exposed on our local computer to port 80 So we could just type local host again and have the power of kubernetes be accustomed to kubernetes because that's what we're going to run in production and We're gonna do we're gonna write our own deployment This is what docker compose that the the translation stage from local docker compose to a full blown kubernetes system did For us, but when we want to go to productions. We have to write these files ourselves. So let's start with the MySQL part. Are you ready? Yes, let's do it This is our service definition all of this all these chip snippets of files and code will be hosted in my case in a Single file single deployment file. We're gonna run that and it will do rolling deployments to the cloud So what we're doing here is answering some of setting some metadata But what we're primarily doing is saying we want to expose the port 3 306 for an app that is called WordPress and Then we're doing some persistent volume claims don't look at the details the ideas that we're claiming one gigabyte of storage from our system from our cluster because it's a Cluster system at the minimum of six nodes tree master nodes tree worker nodes or minion nodes as they call it and Then we have our deployment or my SQL deployment contains similar strategies I know it's a lot of yaml and that's my main concern here lots of yaml What we're doing here is we're naming things we're naming it's a MySQL WordPress We're using that 5.7 image and it goes on right the environment variables you see him What we're doing here, and that's what I wanted to point out to you is using Secrets here. We have a secret that is registered in our cluster that is encrypted and where the passwords reside So have separate ways of doing that So I have all these environment variables and we link far lip my SQLs to make sure that it's attached to that persistent volume claim If that container dies and gets booed up again because that's what the container Orchestrator will do if something dies it will reschedule it automatically and you can have replicas so that you have multiple Versions of this and it all will get bound to far lip my SQL in that way you have safety about the storage of your data Because that matters and WordPress again similar service which service port 80 We're gonna do type load balancers so that it's load balanced across the cluster if we have multiple replicas We'll have a 1 gigabyte storage in this case We're gonna have the very similar things. We're gonna host the latest version of wordpress have some made of data here Have all these parameters here so that it's bound Use the storage yada yada yada What I'm doing here again. I'm sorry. I'm gonna put it in my command line history I'm gonna register those secrets. You can read them from a file again. It will be stored nicely and securely within the cluster and then We're gonna do cube see and this is the magic This is what happens keep CTL apply minus F that entire file with that huge Yawl definition and it will automatically orchestrated in the cloud and it will load balance it And you can have replicas and all that you want and you can check the pods and the pods are there They're first at first. They're not ready for creating the containers and they're running You're up and running and you can run all that stuff and you can get the services and the services are there And you're good to go and you can get the deployments then and you can say we're gonna scale We add two replicas so that it's load balanced on the fly Again, it will run it and there will be a desired state of two So I'm not gonna go in all those details But what I would advise you if you want to really really feel the power of Kubernetes locally on your system Is to install mini cube a mini cube as it says is a miniature version of kubernetes That only contains a single instance hosted in its own little virtual machine. I think primarily on your Mac Maybe you can have it on Windows as well. I'm not sure And then you can do these kinds of things the service that is defined on port 80 Well, then you can do mini cube service minus minus you are all WordPress and you'll get the URL You could run you don't have to care about all the networking stuff because that cluster IP kind of thing that is hosted Even in DVM you can't really touch that because again This is all Linux and your MacBook and your Windows that is not Linux So there's a little virtual machine in place to make that happen And when you want to when you're too lazy to copy and paste that URL You can just do mini cube service WordPress your browser will open and you'll see the service That's a way of abstracting it when you go into the cloud it all depends on your vendor and Company you work with how it's gonna get exposed to the outside world via HTTP or what have you and then if you're curious about what runs on kubernetes You can type mini cube dashboard and it will open the kubernetes dashboard. You can see all the bells and whistles And when you're ready for production when you want to go to deployment I have two minutes left. Maybe that's one by now And we're getting there. We're reaching the end. You only have six more slides You can do Qubectl config use context and you can switch to a production context So you'll have multiple contexts. You'll have a development and maybe a staging and a production and an acceptance Or you have something at Google something at Combell something at Amazon you can switch and then just apply that same Configuration file that by now you don't want to look at anymore. We just built it. It's there and It's done And believe me. There's more There's a lot more. It's a lot more, but that's that's a story for another day. I just wanted to dive you like take you and dive right in into the wonderful world of WordPress and Docker I understand and accept that it's quite hardcore quite technical but I do believe that it's a way that is passing by right now and Might as well want to ride it to take your surfboard ride that wave because the future is definitely going to be containers I'm not sure if Docker will be the technology that will be out there in the next 10 or 20 years But containers is definitely something you have to look at that being said you can find these slides will be published on E.U. Later on you'll see a list of my past and upcoming talks if you want to see more that stuff Follow me there, and I'm on Twitter Instagram. You name it I want to thank you because we've reached the end and you haven't fallen asleep most of you I guess and there's drinks outside and But unfortunately word camp and rip is done. So thank you for sticking around see you next time Thank you for hanging out with me


Stoker double defense, 12 gauge over under and I really do like this a lot. It's a little more tactical looking anyways than the coach gun. Rails all throughout. You can see a rail up top. The slots in the rail don't go all the way through or shall I say the slots go through but the rail doesn't because it has a nice tunnel leading right to a green fiber optic front sight. Serrated rib 20 inch barrels fixed improved cylinder choke. Has the action lever up top and extractors where you manually have to pull out the shelf. Each time the action is closed you have to flip that thumb safety forward. Has a recoil pad here that the coach gun does not have. I certainly appreciate that. I'll take a few more shots. A nice quick trigger.