It’ll build everything for you automagically.
I wondered about that - but part of the point of moving to docker for me was to keep HA vanilla so it was less likely to get broken.
If you only add one or two packages to the image that don’t conflict with anything included in the base image already then you’re probably gonna be fine 
Yes it’s a good container.
The containers are always uptodate… but if a bugged version is pushed on repository, the update will be auto…
watchTower update also the container watchtower ;p Happy docker technology ^^
Yeah, thats a concern…
But you can flag your mission critical containers not to get updated automatically
The only thing I wanted to add was a self-cert-expiry checker that was suggested elsewhere in the forums. I’ve never tried altering an image though 
And it should notify you or something
It’s quite simple, just make a basic dockerfile that uses the hass image as the base and then copy in the binaries that you’ll need (easiest way imho)
And would it pull the latest hass image each time, so I don’t lose the auto-updating I get from just using the standard image?
I’m still a bit of a docker noob. I went through my various apps replacing them with docker containers but so far I’ve just been pulling pre-made images from docker hub, often through Portainer.
Yep. As long as you set the tag to :latest , then it should do just that.
1 Like
But you’ll have to rebuild your image
Thanks for this.
I can probably move my command line sensors to MQTT to keep the docker as standard as possible, but I have a couple of shell_commands that still won’t work, like the auto renewal of the SSL certificate.
Any suggestion on how I would approach this?
Similarly how would I run a shell_command on the host by passing arguments to it from the HA docker?
1 Like
In my opinion, Docker should solve a problem and not all problems can be solved with Docker. As soon as you begin to add complexity you lose the advantage of the sealed container and can end up with a far harder mess to debug/troubleshoot, integrate and repair. The old saying goes “If all you have is a hammer, everything starts to look like a nail”. I’m not saying that Docker isn’t a good choice, just not the best choice for everything.
Thanks I appreciate your views. At the moment I’m stuck on 0.64 as the max python version on Ubuntu 16.04 is 3.5.2, and 0.65 requires 3.5.3 minimum.
I wanted to move to docker to not have to mess with python 3.6 on my ubuntu core, and apart from the few scripts I have, docker is brilliant as all the behind the scenes work is taken care of.
I’m just looking for the best recommendations to convert my scripts / move them away from the docker while still being able to interact with HA.
I can easily move my sensors to MQTT so that’s one problem solved, but I’m wondering how I could change/convert my shell_commands to allow HA in the docker to call a command that would eventually run on the host…
My comment was a general one since everyone seemed to have a Docker does everything stance. It isn’t hard to install python 3.6 on 16.04 or do a release update to bring Ubuntu to 17.x. Pretty quick either direction. Do you have other things running on the server that would prevent you from moving to 17?
I’d rather stick with the LTS version for now. The next one is planned next month, but the last 2 times I had loads of issues so considering moving to docker as it will also mean it’s much easier and quicker to recover from a system failure and/or OS reinstall. Plus I like the fact that HA will run in its own container, so grand plan would be to eventually do a OS reinstall and run everything in docker containers…
Thanks for sharing your views/experience
Not to belabor this but how hard is pip3 install homeassistant. Forget about the venv. I can copy my configuration to a totally new device, run the install and be back up where I left off in 15 minutes. With a bunch of containers and varying levels of interactions, you can be hours trying to tie things back together if you have a failure.
Another watchtower user here. I have a total of 9 containers running that do various server things for my house (plex, sonarr, etc.) and I have watchtower set to check every day at 4am if they need updating. If so, it pulls the new image, re-creates the container, and re-spins the container using the same arguments it had been launched with originally. Bottom line, everthing is just always up to date.
The one exception to this is Home Assistant. I do not have watchtower updating that. I always want to check the “breaking changes” and give it a day or two for the x.x.1 release that fixes the immediate large bugs. For that I use “Portainer” - in there, I just click “recreate container” and it offers to pull the latest image… so it’s just a one-click update for HA.
2 Likes
I tried Docker and, while i easily got HA to run, I just never could figure out the interdependencies required for HA/SSL/NGINX/MQTT/SSH/shell commands/Zwave/Zigbee/etc…
After a week or more of pulling out my hair trying to figure out ports, binds, reverse proxies, SSL keys, etc, 
I eventually just installed a straight Debian 9 OS, updated to python 3.6.3 and installed HA in a venv on my NUC.
It acts exactly like the install on a RPi (which is pretty straight forward).
I agree that once you start modifying the base Docker containers for individual requirements then things get trickier to recover from. Like I said, I couldn’t wrap my head around a pretty basic HA functionality in Docker not even having any more complex stuff to figure out.
But that’s likely just me…
3 Likes
One parting comment. The instant you cede control of the building and looking after your stuff, you are forever at the mercy of whoever does the building. You lose the basic understanding of how something works or doesn’t. If the builder loses interest in maintaining or some component in the thing goes away you are minus the experience you would have had creating it yourself.