Desperate time calls for desperate measures. With whole amount of job sites and even social networks, it seems to be just useless, when recruiters comes to you with totally opposite position. Usually, you are pleased by attention, but for sure, it’s not about your visitor, who cannot read your CV. And what about everyone. who asks you to send latest CV? What’s the sense to keep it up to date with latest projects, referrals and achievements in one place? And what about big companies, who ask you to put your CV with Linkedin profile at same request?
OK, of course, I don’t have any answer on this mysterious questions, and only thing we can do – try to highlight your CV, or have it somewhere in a short way or, even, try to stand out from the crowd.
My way to success (have no any idea about success rate ) come across idea to create CV site. It’s simple to do it: wordpress, another docker container, nginx and DNS, seems to be simple. But, as here we are discussing about overengineering of any basic tasks, we keen to create pure mixture of homelab essentials and going to use Kubernetes, Gitlab and something in between.
Action list:
- Create DNS records, certifications and so on
- Setup nginx, traefik or whatever you need
- Create site to piblish
- Create pipeline to deploy this site
- Create deployment to deploy site
So, first 2 points – not a problem. usually. it can be automated also, but not now. Let’s just jump to third one to start funny parts.
To check something new and evaluate great abilities of static sites, let’s start with famous Jekyll. At first glace, it seems to be a easy task, but in reality I had to amend original plan and build a site.
Jekyll
Eventually, all the fantastic ideas about static sites is about to build even one page with the building a Dockerfile in this case. So, action plan – combine 2 repos in one and build it together. First one is a CV template itself and second one – Jekyll, that we need to put in a container.
In general it really works fine and nice. It takes around 2 minutes to build an image and, when it’s done, it start immediately.
Few words about Jekyll from wiki:
Jekyll is a static site generator. It takes text written in your favorite markup language and uses layouts to create a static website. You can tweak the site’s look and feel, URLs, the data displayed on the page, and more.
Seems like it mostly used to run a sites on S3 buckets for few pennies or in a GitHub pages. Seems nice, but in our case – it’s just a way to taste something new.
At the backend it using Ruby, that claims to be a best programmer friend, that actually builds everything. To build static site from scratch it takes about 2 minutes to create it.
Gitlab
As Gitlab is one of the most long-living container in the homelab, it’s not something cutting-edge, but this time it was old dog with new tricks. Initial problem was related with upgrade and migration of Gitlab container, that force to restore it from backup. Eventually, it worked perfectly fine with just few permissions issues and a bit of lost keys as for deployment and for users.
So, main point with Gitlab is to build an image and deploy it to Kubernetes. By some fantastic reasons, it never been used in the lab, so, it’s time.
Using several articles, we can build following flow:
Few comments about points above:
Initial attempts to build Docker-in-Docker mostly failed because of the complexity, absence of transparency and over-overengineering. Another point here is amount of articles to understand the topic. So, usage of kaniko seems to be a more simple and obvious way for trivial task.
Push task is simple but due amount issues related with Gitlab restore, mostly, it was related with basic file system permissions issues on container level.
Deployment to Kubernetes itself is perfectly fine working in a pipeline, the only thing, that annoys is basic pipeline failures as absence of creds, wrong volumes and so on.
Kubernetes
This thing finally become core container orchestrator in the homlab, logically replaced docker in whole variety of used services. At the end of the day, it was just working. As an option, could be used helm charts from repos, but in this example we used simple deployment.
Results
Expected result of this exercise is increased amount of hits on my CV and nice way to build CV in automated, consistent way. Additional customization to make some fun, as current way to attract recruiter doesn’t work.
Conclusion
Original plan was to create a static CV with ability to put it in profile website on Linkedin, as this one, at least, seems to attract people and force them to read it, at least, somehow.
To prevent too wide and useless spread of CV with personal data (any of it ), we can fix it with robots.txt.
And, to count hits of visitors we can include any kind of statistics code there. In my case, it was Matomo ( former Piwik).
