Etiqueta: Practice

DevOps and Linux practice reflection

en por maku18blogen TC3045Deja un comentario

During this month I have been practicing some common DevOps activities like setting up a repository, opening a server and updating it automatically with cron. Some of them were easy tasks because I’ve already done similar activities, but there were other task that I had no idea how to do and it took me a while to figure it out.

If you want to see the whole process I’ll link the part 1, part 2 and part 3 here. On this post I’m going to talk about my experience doing this activities and then show the results.

The first part was easy, most of the step were things I already had like the Linux distribution(Ubuntu 16) and all the development environment. I had to struggle a little bit with cron because I din’t know how to make sure it was running, but after reading a couple of tutorials I found that I had to send the output to a file with the «>>» symbol.  This operator appends anything I pass to the file without eliminating what was there before. This is an example of how my cron file looks:

* * * * * [path]/bashscript >> [path]/log.out

For the second part I also had experience using SSH keys for GitHub, I use that all the time now that I have 2FA because for the terminal it won’t let me use my normal password. To code the server I used NodeJS and ExpressJS because those were tools I was familiar with for this kind of things, later I had trouble with that but for this part it did what it had to do, the script moves to the git folder and pulled from master. Just to keep track of what was happening I kept the log file. During a period of time the script created a file and after doing all the stuff it had to do deleted it, that was surrounded with an if conditional that checked if the file was created. I deleted that on part 3 to simplify my tests because while I was working on it I had no idea what was giving me errors.

Finally, the part 3 was the most difficult for me. I quickly created a Maven project and in 5 minutes I could run the test without problems. The tricky part for me was that I could not find the way to read a file with the tests results and pass that to the web page. I tried a lot of ways and after a lot of failures and attempts to debug my code I learned that ExpressJS was not made to host HTML files. My HTML contained the JS that reads the tests results, that JS script was run in an environment without the proper modules so it didn’t work. My solution was to format the tests results files to have the proper HTML tags and then put that into a static HTML. This is how it looks:

devopsnapshot.PNG

It’s not pretty, but is useful…I guess. The code of the practices is available here

Overall, I enjoyed learning and using things that I don’t normally use, like cron or bash scripts. I think these tools are really helpful and I would like to learn more because I could find more interesting uses to it. After doing a little bit of research I found tools that could’ve helped me to do this easier. Jenkins is a tool that automates the whole development process, it’s open source and free. Kubernetes is another tool for automation but this one works for containers, from what I’ve heard is harder to learn and it’s not free. Both of them use Docker, a tool to containerize apps that I’ve hear a lot but haven’t had the chance to use it and learn why is useful. I think that all these tools are really powerful but sometimes complex, I need to learn how to use them well before implementing anything with them.

Now I know that doing all these tasks can be a lot of work and requires a lot of knowledge and experience to do some high quality automation.  Being a DevOp also requires a lot of creativity, each environment is different in hardware, software and people, the DevOp has to have a different set of abilities to solve each problem, whether it is about automation scripting or people management.

DevOps and Linux practice pt. 2

en por maku18blogen activity, TC3045Deja un comentario

After setting up our development environment and practicing a little bit with cron in part 1, it’s time to do something useful with it. But first, lets make sure that my repository and account are safe.

1.- Setting up 2FA

GitHub has the option to connect with 2 factor authentication to your account, I have activated this option and now after signing up in an unknown device they ask for a number that they send to my phone via SMS. Now, whenever I try to push from the terminal when I’m not logged in it won’t accept my password account, this happens because with 2FA I have to generate a token and use that token as my password. I use two tokens, one for Linux and the other for Windows, they both have the minimal permissions to let me push into the repository but not delete or modify anything important from that repository or others as well.

2.- Setting up SHH keys

To avoid copying and pasting that token each time I want to use my account in the terminal there is a alternative, the SSH keys. To generate one I followed this complete tutorial, now I can connect with the key from any place I want.

3.- Cron server update automation

Now for the cron practice, I already changed the bash script to do a pull instead of just printing hello world. Also, I considered to change the cron file to run the script every 12 hours. I’m still not sure how often I should update, or how often companies do it in a real life development environment, but 12 hours seemed reasonable for me because it updates the server when people(me) are supposedly not updating the repository. However, the problem with this is that if someone pushes a broken piece of code, it will not be fixed until the next 12 hours or that someone corrects the bug and pulls manually from the server. For this practice I need to watch consistent changes, so I’m going to change the script to do a pull each minute. Whenever the server pulls any change, the website updates with a refresh if it is a simple change like a text line in the html, but I need to run it again if something like new dependencies and a JS script were added. I’m not sure if this happens because I’m using NodeJS to run the server or if this is a normal behavior, but Node already has some solutions related to this, check this site if you want to see how to use the node demon or you want to avoid refreshing the web page each time the server updates. I’m not implementing any of this for now, but I will consider it for the next practices. To ensure that the server is not running two copies of the same script there are several techniques, a simple solution is to create a file and after making the pull deleting the file. Before creating the file we should check if it already exists, if it does, then wait until the script that created it deletes it; if it doesn’t exists; then there is no concurrency and everything should execute normally.  I added this solution in the bash script, to do that I had to learn first how to do it. This bash cheat sheet helped me a lot, I think is a very useful resource when you are coding scripts.

Python unit tests

en por maku18blogen activity, TC3045Deja un comentario

Today’s activity is really interesting, we have to do some practice with python unit testing. According to the official unittest documentation, it’s very similar to JUnit, so we should have no problem understanding it.

Now, here is a picture of me using hypothesis to do annotations on an old web page that we are able to see thanks to Wayback Machine.

hypothesisEvidence

While playing a little bit with Wayback Machine I found an old version of Steam’s page, the popular PC gaming platform, back in 2002. Its interesting to see that web pages were not that colorful or filled with images, this design was simple but worked really well.

oldsteam

For the next part, we have to see this Unit Testing and Test Driven Development in Python course where we will learn to set up virtual environments and unit tests using Pytest. For the exercises we are going to use PyCharm, a Python IDE that will make easier for us to run tests.

evidencepytest

The tutorial was fun and explained very well the basic functionalities that Pytest has. The activities were helpful summarize all the material and I felt that they were easy to do and understand.  Overall, Pytest is a very simple but powerful testing framework for Python, it’s really easy to use and has a lot of functionalities that solve testing problems like mocking objects and exceptions catch. It’s easy to setup as well, thanks to PyCharm I had no trouble at all when I was implementing my first tests. All the time I felt like I was using JUnit but with different syntax. At the end, Richard Wells also explained some TDD good practices, and one that called my attention was to run tests in random order, I hadn’t thought that it’s important to make sure that tests should run in any order which means that they don’t have any dependencies between each other. For other specific testing processes like coverage tools, advanced mocking or linting there are other libraries or modules that work very well with Pytest.

DevOps and Linux practice

en por maku18blogen activity, TC3045Deja un comentario

This week we are going to learn about Development Operations. Its a topic that I hear very often in the industry and I didn’t know really well what this was about. If you want to learn more about what DevOps is, I made a blog post summarizing a reading about that here.

For this blog I’m going to be completing some task that show the job of a Dev Ops engineer in a simple way. For each achievement I’m going to talk about my experience:

1.- Install a Linux distribution

I already have a partition of Ubuntu Desktop 16 in my laptop, I use it for some classes or when I need to go full developer mode(no video games). I installed it a while ago, I chose Ubuntu because it is a popular choice for newcomers and students. It’s easy to customize and looks pretty, there might be better choices but at the moment I don’t have the necessity to change my Linux distribution.

2.- Install support for your development environment.

This task is really important, here is where we chose our tools, programming languages, text editors, libraries and everything else we need to have our development environment ready to go. Most of the choices I made here were just determined by preference. It’s important too that you customize your environment as you want, choose the text editor you are most used to, the tools you prefer and the themes you like; remember that you are most likely be working here a lot of time, so it does not hurt to make it easier for you.

Languages: I already have Python 2 and 3, Java, C and C++. That includes any compiler or installation needed.

Code editor: For big projects I installed Visual Studio Code, it’s a really robust editor with a lot of functionalities and a lot of extensions created by the community. For quick edits I like to use Sublime, it may have less functionalities than VSCode but is faster and also looks pretty.

Tools: I installed Git for version control, Conda to handle several environments and NodeJS to make Web Applications easily.

3.- Setup your first test use of Cron on your server.

Crontab is a very useful tool to run scripts at specific times. It’s really simple, this tutorial is enough to understand how to create a crontab file. For this practice I made a bash script that prints «Hello world» and runs every 5 minutes.