The latest articles on DEV Community by Vedran Mihočinec (@vedran). https://dev.to/vedran https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F727649%2F128b578d-8395-4f85-bf98-ecca4eef0a62.png https://dev.to/vedran en Vedran Mihočinec Mon, 29 Nov 2021 21:06:29 +0000 https://dev.to/vedran/the-easiest-way-to-dockerize-a-php-application-4jne https://dev.to/vedran/the-easiest-way-to-dockerize-a-php-application-4jne <p>What is the easiest way to dockerize PHP applications? Let's find out with the GitHub repository example.</p> <h2> Architecture </h2> <p>In order to create scalable architecture, we will dockerize two apps that will use the same reverse proxy. </p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--vrBofJh_--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4574gyems9fhri1b7d96.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--vrBofJh_--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4574gyems9fhri1b7d96.png" alt="Network" width="880" height="431"></a></p> <p>Services can only communicate with other services on networks they share, so we will have three networks:</p> <p>1) Proxy Network which contains Reverse Proxy (Nginx), Best App (Apache/PHP), and Awesome App (Apache/PHP);<br> 2) Best Network which contains Best App and Best DB (MySQL);<br> 3) Awesome Network which contains only Awesome App.</p> <h2> Requirements </h2> <p>Requirements for our architecture are:</p> <ol> <li>There are no permission issues;</li> <li>Xdebug works out-of-the-box;</li> <li>Every application has a unique domain;</li> <li>We use HTTPS;</li> <li>Setup supports multiple applications.</li> </ol> <h2> Permission Issues and Xdebug </h2> <p>To prevent permission issues and have package availability out-of-the-box, we will use <a href="https://github.com/thecodingmachine">thecodingmachine/php</a> for PHP applications, a general-purpose PHP image for Docker. </p> <p>We will use its <a href="https://github.com/thecodingmachine/docker-images-php#fat-image">fat image</a>, as it comes with <a href="https://httpd.apache.org/">Apache</a>, <a href="https://github.com/aptible/supercronic/">Superconic</a>, and <a href="https://getcomposer.org/">Composer</a> and it already has common PHP extensions enabled.</p> <h2> Unique Domains, HTTPS and Multiple Applications </h2> <p>In order to have unique domains, HTTPS and multiple applications support out-of-the-box, we will use <a href="https://github.com/nginx-proxy/nginx-proxy">nginx-proxy</a>, as it supports everything mentioned above.</p> <h2> GitHub Repository </h2> <p>As we have defined the architecture and tools we will use, this is the part where you should visit <a href="https://github.com/v-m-i/simple-php-app-dockerization">https://github.com/v-m-i/simple-php-app-dockerization</a> and see how to configure and run everything mentioned so far.</p> <h2> Outro </h2> <p>This post could have been a lot longer, but I've kept it as short as possible because everything should be explained in the example repository.</p> <h3> Is the Easiest Way the Best Way? </h3> <p>It depends on what our goal is. If our goal is to create an optimized, clean and precise docker environment, then it's not the best way, as it's a fat setup. But if we want to dockerize our app for our local development in the fastest and hassle-free way, then it might be the best way to do it.</p> docker php webdev devops Vedran Mihočinec Sat, 16 Oct 2021 20:36:24 +0000 https://dev.to/vedran/debugging-mindset-3n77 https://dev.to/vedran/debugging-mindset-3n77 <p>Bugs here, bugs there, bugs everywhere. Some are easy to fix, some are complex and obscure. So, is there a generic approach to fixing every bug? Probably not.</p> <p>Anyway, there are four parts of fixing a bug:</p> <ol> <li>Understanding a bug;</li> <li>Identifying the cause of a bug;</li> <li>Planning a bug fix;</li> <li>Applying a bug fix.</li> </ol> <h2> Understanding a bug </h2> <h3> What are the steps to reproduce a bug? </h3> <p>It is crucial to have as much information as possible about a bug, even if some of that information ends up irrelevant. For example, knowing at what time which user on which platform with which input got which output. You should almost always have all the required information already written in the bug report and if you constantly end up asking this question, then consider writing a list of required information for reporting a bug.</p> <h3> What is the expected flow? </h3> <p>Sometimes features end up reported as bugs. And that's okay, as developers don't know every part of the application code the same way bug reporters might not know about some feature. So it's important to have the expected flow explained in the bug report.</p> <h3> Is your bug a bug and is expected flow an expected flow? </h3> <p>As mentioned above, not everyone knows everything and features might end up reported as bugs. So, if you think a bug needs to be challenged, challenge it.</p> <h2> Identifying the cause of a bug </h2> <h3> What does the log say? </h3> <p>If you know when a bug happened, are there any logs that might help you? Remember to consider all log types: system logs (example: OOM happened), application logs (example: required third party service was unavailable), third party logs (example: unoptimized database query resulted in slow query execution), etc.</p> <h3> How does the flow behave in your local environment? </h3> <p>Try to reproduce the bug in your local environment. After you reproduce it, turn on a debugger and try to figure out where the bug is in the code. If needed, write down suspicious points and ponder over them until you figure out where the bug is.</p> <h3> How does the flow behave in the production environment? </h3> <p>If you can't reproduce the bug in your local environment, then it might be time to try the production environment. Based on identified suspicious points, use remote debugging or write the information you need in the application logs (example: "If logged user is me, then the log information I need (input data, execution time, etc.)"). After you have that production information, try to reproduce it locally again. And finally, if you didn't use remote debugging, remove added temporary logging code from production.</p> <h3> What if we can't identify the cause of the bug after all the steps mentioned above? </h3> <ul> <li>Talk to a duck</li> </ul> <p>Explain the bug and all the steps and findings to a non-person. Just by explaining, some ideas might pop up.</p> <ul> <li>Talk to other developers</li> </ul> <p>Explain the bug and all the steps and findings to other developers. Maybe you will get some advice or tips on what to check.</p> <ul> <li>Give up (temporarily)</li> </ul> <p>Add detailed logging to all identified suspicious points (be careful not to impact the application performance), write down all your findings, deploy code with detailed logging to production and wait for the bug to occur again.</p> <p>Explain to your client that you are unable to reproduce the bug and that you have added detailed logging so you will know when the bug occurs next time and that you will try to fix it again at that time, with new information you will have.</p> <h2> Planning a bug fix </h2> <h3> "Is your bug a bug and is expected flow an expected flow" vol 2 </h3> <p>With new information, ask yourself if there is a need to challenge the requested flow. Maybe there is a reason the flow behaves the way it behaves. Maybe the problem is wrong communication to the end-user. Maybe there are security, performance, or some other kind of issues that might occur if that flow is changed. Always check code history where the bug occurs, maybe there are some linked feature requests or explanations for it.</p> <h3> How many entities are affected by this bug? </h3> <p>It's good practice to check how many entities were affected by a bug. It might lead to different bug solutions or maybe the client might want to know that information.</p> <h3> Can you reproduce a bug with a test? </h3> <p>If you can reproduce a bug with a test, plan to write the test.</p> <h3> Do you need a hotfix? </h3> <p>If you need to fix a bug ASAP, then plan to create a hotfix.</p> <h3> Did the bug cause some data corruption? </h3> <p>If some data is corrupted because of the bug, analyze the impact and plan the solution for data corruption. For example, you might have to create a background process that will fix all corrupted data, or maybe you might need some manual intervention to fix corrupted data.</p> <h3> Do you need to remove added logging? </h3> <p>If you have added some detailed logging to better identify the bug, maybe you need to remove it.</p> <h2> Applying a bug fix </h2> <ol> <li>If needed, create and deploy a hotfix. A hotfix can be ugly, but, ideally, it should be accompanied by a test that confirms that hotfix works.</li> <li>Fix the bug according to your application coding standards and, if possible, write some tests for it. If you added some logging that is not needed anymore, remove it.</li> <li>If corrupted data exists, fix corrupted data.</li> </ol> <h2> Outro </h2> <p>These are the steps I often go through when I work on solving bugs. Most of the time there is no need to go through all these steps, but hey, here they are.<br> And there is still one important thing to mention:</p> <h3> How to estimate bug fixing? </h3> <p>When you have all the information about the bug, somebody might need an estimate on how long it takes to solve that bug. That's easy when the bug is obvious and (probably) easy to solve, but how about when it isn't? Here are my rule-of-thumb rules:</p> <ol> <li>Create a task for identifying the cause of the bug and estimate it to a maximum of one day. If you can't reproduce a bug in one day, give up (temporarily) and create a follow-up ticket for a time when the bug is detected again.</li> <li>If you identify the cause of the bug within one day and you can fix it in the remaining part of the day, fix that bug.</li> <li>If you can't easily fix the bug, create follow-up tasks based on your plan for a bug fix.</li> </ol> <p>And that's it, I hope this article helps you in your future bug fixing ventures.</p> <p>Have fun!</p> career programming productivity webdev