Add Docker support

To help with development and potential set up of production systems. I have branch on my Github. I did need to create a Dockerfile so I could add additional modules needed for Gibbon to run. If this is accepted it could be used to create an image in a docker hub account owned by the Gibbon maintainers. Let me know if I can help in any other manner wit this.

Hi Lucas, welcome to the Gibbon community!

For development and testing people seem to use a variety of platforms (MAMP, XAMPP, Vagrant). I haven’t seen anyone using Docker yet, perhaps you could share the dockerfile (as a Gist?) for any devs keen on checking it out :smiley: Thanks!

For production releases, Gibbon tends to aim for a low barrier of entry (ideally as easy to install as WordPress, etc.). Many schools aren’t running the same cutting-edge software that devs like to use, and I bet containerization isn’t on the radar for many school IT departments.

I work for a company that does technology in schools and you are right for the most part. The majority of schools are not using docker (yet). We are working hard every day to push technology in schools and docker and AWS/GCP are a big part of that. I already have a branch with the code in there so here is the Dockerfile and here is the docker-composer.yml file. I went ahead and generated a SSL cert for it as well which obviously wouldn’t be used for production but I prefer to use https as much as possible. Let me know what you think.

Awesome, thanks for sharing! I’d be keen to hear more about the work you do :smiley: We’ve been working to push the Gibbon codebase forward in many ways, not quite to the level of containers and cloud computing, but there’s many neat incremental changes happening with each version.

Not sure if this is the right place for it or if you were thinking some where else. I have worked for Five-Star Technology Solutions for 3 years as Software Developer since February of 2017 I took on the role of a DevOps Engineer (I was the only person with history/interest in networking or servers on our small team) and also lead a team of 2 developers on our latest project Pyxis a Professional Development website for Certified Staff at schools. I absolutely love education and teaching but technology has an extra special place in my heart. Anyways on to why I am interested in Gibbon. Our larger and much more popular piece of software Pivot works with a lot of SIS systems and being the idea person I am I was looking for a solution that we could adopt and perhaps even support as a company. With Powerschool, Harmony and Skyward we have so little control of what happens so I am looking for open source solutions to pitch to our company as viable options for us to suggest and support for schools. Gibbon seemed like a logic choice because it seems straight forward, very extensible and written in PHP a language our team is very familiar with.

On my own I am still looking at creating a SIS in whatever spare time I get. I want a SIS that is RESTful API very first and foremost because in my experience getting data in/out of an SIS is always the issue that causes the largest hangup and most schools can’t afford data specialists. Then create a modern single page app using javascript framework like Vue or React. Eventually I want to turn that into a school management software like transportation management, cafeteria services etc… all open source and all able to talk easily with that SIS API. My business model is support which seems to work pretty well with schools because I want to make sure if a school can’t afford the software support itself but have talent people on staff then they will never be held back. Which is why I love Gibbon and what is stands for! WOOT FOSS! Okay, I am done that is just a bit about me just love to help and love to serve others.

Hi Lucas, thanks for sharing all of this background about yourself and your ideas. A lot of your thinking sounds exciting, cutting edge, and exactly what education needs. I guess my question would be (and this has been asked of me many times), why start your own project, when there are others to join? My reason for asking this question is that you’ve found Gibbon at a unique time, as we transition from a legacy codebase to something much more modern. @ross is leading this work, and we are very much looking for programmers to join us, to help with the work itself, but also to begin offering input on different directions we might take longer term. Our current focus is on completing an object oriented refactoring of the codebase: forms are 98% done, tables are next, and then we will move on from there. The aim is to reproduce the existing functionality (which is fairly extensive) in a far more modern, scalable and maintainable form.

Your API point is extremely interesting, not least because I’ve spent a lot of my life moving data around between various school systems. If you take a look at our Extend page, you’ll see a module called Meet The Teacher, which has a partial-API designed to allow Gibbon to talk to a specific online system ( This has worked brilliantly, allowing Gibbon schools to have their data seamlessly synced into a third party system. I see this as an excellent first step towards an eventually more powerful and configurable API.

We’d love to have you join us, should you be willing to roll up your sleeves and get your hands dirty with some legacy code. Cheers, Ross.

@admin I haven’t looked through the Gibbon code base enough to make a decision one way or the other. I guess part of it really is selfishness because I currently work all day on a 10 year old code base in PHP that is completely legacy (html in with business logic, GLOBALS all over the place, SESSION that does the job of a cache etc…) and when I code outside of that I want it to be TDD with all the nice parts of being outside of what I call “legacy land”. I suppose this sums it up pretty well whatever I would come up with would just be yet another standard done another way. I love to program but truly believe that some things shouldn’t be refactored they should be rewritten because it is not possible to get some of the core principals that come with API first design out of what was once legacy code. However, Ross I will say this I need to give Gibbon more of a chance I have not read through the entire schema for the database or the entire code base yet. So I will give it a shot, honestly I think it is my work experience makes me shy around legacy code because I have seen the last 3 years of the organization and I don’t need/want that outside of work but I shouldn’t assume that is how this community is. Just a little nervous around anything legacy.

Hi Lucas

I can absolutely relate! But I’m also a recent legacy-code convert (with the help of some awesome podcasts), so I wouldn’t necessarily trust my opinion on the subject anymore :smirk:

As Ross mentions, this is indeed an interesting time for Gibbon, with some neat changes underway. Our development philosophy is to make incremental testable changes and integrate them frequently into a pretty stable development branch (which runs in production at a few of our schools). To that end, the refactoring approach we’ve been taking is wide rather than deep: one change, repeated across the whole code base. Sometimes slow-going with a small team, but we’ve made some great gains in the past few months.

The object-oriented rewrite has been inching us closer to a goal of introducing an HTTP Request/Response routing model (PSR-7/PSR-15) as the application foundation. I’m a fan of automated testing so we’ve also been introducing CodeCeption tests to cover the legacy code as we go, hooked up Travis CI to run the tests, plus re-worked the docs to automatically build from a github repo.

But… if you checkout the repo you are guaranteed to see legacy code! Some of it is transitional, some of it is straight up html-business-logic-frankencode.

You’re right, sometimes a rewrite outweighs a refactor. Personally, I think the community + code base has a solid foundation and a lot of heart, it may not be as shiny and modern as some (yet!), but it’s continuously moving forward. I think this sustainability is due largely to the pragmatic approach Ross has taken with development over the years; setting regular release cycles, developing incrementally, and placing a strong focus on maintaining the stability of the platform for all the schools who depend on it.

You’d be welcome to join our developer slack, to at least check things out, share some insights (or cautionary tales), and ask any of the questions you most certainly would have should you dive into things :smiley:

I would love to get in the slack channel. Do you have a link?

Sure, Ross can add you, send him an email at (I think he may be away on holidays now though).

Sounds great will do.