Important Update: 0.5.6

I’ve been experiencing various issues with Cyca’s docker image. As I said in an earlier post, I don’t really have experience with docker, so my image was far from being perfect. It still is, but it should be working, at least.

Wrong root URL

First issue, although not related to docker, was related to routes used in the frontend. Until now, I have been using ziggy to make routes defined in PHP available in the javascript code. Unfortunately, I didn’t notice that during compilation-time, the library hard-coded the URL from the APP_URL environment variable in the .env file into compiled javascript. As a result, I’ve discovered, the hard way, that no version of Cyca was usable. Big bummer.

I didn’t noticed until my best friend tested the app, because, even if I tested the app on the same host as the “dev” app, so the URLs pointed to a valid running server, just not the good one. And CORS didn’t help since my proxy server also pointed both hosts (the “good” one and the “bad” one to the same backend). Long story short: I really need a dedicated computer to setup a proper network lab. Which is where you can help: by making a donation which would help me making Cyca better 🙂

Wrong volume

In the docker_compose.yaml I provide I made a terrible rookie mistake by sharing the same volume across the different services in use for Cyca, poiting to Cyca’s root. Consequently, no matter if you downloaded a newer docker image: Cyca’s files were always the ones from your very first installation. Impossible to update. Stucked. Again, big bummer.

So I needed to review the whole docker image building process. I decided to directly install nginx inside the main container. I’m very well aware that it’s not a good practice, but I had to do something that at least works somehow. Besides, it still runs from a dedicated service. I will see later to make this the proper way as soon as possible.

The solution: v0.5.6

Consequently, I just released the 0.5.6 version, which fixes these annoyances. The best thing to do if, by miracle, you had Cyca running already, is to export your data, and start fresh:

  • stop your containers
  • remove every volumes used by the old versions
  • remove old images of Cyca
  • update your git repository (git pull)
  • update the image (docker pull richarddern/cyca:latest)
  • start your containers (docker-compose up)
  • register
  • import your data

I’m sorry for this to happen. But honestly, I’m a bit frustrated by docker and the whole process of making images.

One of the biggest lies in IT

It’s funny somehow because, earlier this week, I read an interesting paper: Devs are managing 100x more code now than they did in 2010. And I think it’s true, at least on one key point:

The profusion of Web interfaces—with shifting standards, platforms, and libraries—hasn’t made software development any simpler

Docker’s case

The thing is, building an application today “requires” to publish it on the Docker Hub. On the plus sides, it allows to package your app, and make it more or less cross-platform. It’s also supposed to increase security, and make the process of publishing your app easier. All of that is true, as a newcomer, I can confirm.

What’s forgotten at this point is all the work that must be done before getting to this point. And, frankly, Docker’s documentation is not the easier to read, or even to browse. These colors, the generic font, text size, you get lost into versions, etc. So getting up to something functional is already a burden.

There is an aspect that also frustrates me with docker: there is no clean way to make things a bit more flexible. For instance, I wish I could define environment variables inside my docker-compose.yaml file, that can be shared across different services. As for now, and unless I’m missing something (which totally could be), the only way to do that is to have an external file to hold the variables. And, when you build an app that can support different services for one purpose (for intance, databases), you have to build one image per combination. Imagine having one image for Cyca + MariaDB, one for Cyca + PostgreSQL, one for Cyca + SQLServer. How about web servers ?

  • Cyca + MariaDB + Apache
  • Cyca + MariaDB + nginx
  • Cyca + PostgreSQL + Apache
  • you see the point

So, as a dev, I built an app that is flexible, but as I “have to” put it on docker, I have to limit it somehow. This is frustrating. Both to me, and my users.

Not to mention the size of the thing. Latest uncompressed archive of Cyca’s files weights a bit more than 5MB. Uncompressed docker image weights a whopping 1.6GB. Sure, my archive needs to be installed on a properly installed server, which, once usable, will use nearly 1.6GB (my web server under debian uses 1.2GB once everything is up and running for Cyca, including its dependencies). And, sure, there is nothing else to install aside of the 1.6GB of my docker image (except docker itself and the underlying server). Still, it’s a lot easier to distribute a 5MB archive than a 375MB (once compressed) docker image. Plain maths.

The interesting features in the docker hub, meaning vulnerability scanning and parralel builds, are, of course, paid features. I don’t blame them for that, it’s a business model as others. But these are features that could really help making better apps. Security shouldn’t be paid for, being health security, or computing security. But that’s another subject.

Unfortunately, to hope Cyca, and other apps from devs like me, reaches high level of interest from users, it must be easy and quick to install. And docker has a kind of a monopoly on that. Rightfully. I mean, once you support the appropriate architecture (and so do your app dependencies…), you can distribute your app on all kinds of hardware, hopefully in a one-click operation.

This is where the whole “devops” BS leaded us to. A developer cannot be just a dev today. He also must be an ops, meaning heaving strong knowledge about the systems, not just the one he’s being developing on. Sure, it’s nice to make your app widely available (I don’t know, I’m not there yet), but it comes at a cost, entirely for the developer. That’s not something to forget.

GitHub’s case

The case of GitHub is a bit different. It’s a git repository, so by itself, it’s not really user-friendly but at least there is a lot of documentation outside of GitHub. The problem is the documentation about GitHub, which is the opposite of documentation on docker: bright. So bright it’s almost transparent, sometimes, inexistent. From the very beginning of your very first project. Where gitlab shows you a very newcomers-friendly page right after creating your repository, with each command needed to start working with your project, even if you already have a codebase somewhere, GitHub screams against you because you forgot to add the README file. It took me a while to figure out what to do, also because it didn’t like my SSH key. I had to edit my git configuration to add some crap to make my local repositories syncing with GitHub, and 45% of the time I just couldn’t push, no reason, and search on the web was useless.

Last words

Building an app is definitely a LOT more troubles than before. I know, I’m old and bitter, before was better, etc. Yes, I got it. But please, stop saying that it’s easier to be a developer nowadays, or that you can learn how to code in a week. None of that is true. It’s a big fat lie that just makes devs angrier.

I’m going to keep learning docker, because I’m sure I can find a clean way to achieve my goals. I’m going to keep learning from GitHub, because self-hosting my own services can’t be done right now. I’m going to keep learning everything that’s new in my field, because I love development. And because of that, Cyca will grow better. Thanks to GitHub and Docker than bring us robust mechanisms for building and deploying apps.

But, again, stop saying you make devs life easier…