Hey folks, just trying to get an understanding of how to start to build projects using Balena Cloud. I have successfully deployed the hell-world application, and now I’d like to display said application on a kiosk/Browser block. I have two questions:
how could I build the Browser container myself? The usage instructions show just using the prebuilt image, but I also tried cloning the git repo but don’t understand how to include it in my docker-compose.
I have a launch URL specified in the environment: section, but it seems to come up with the default of “http://photo-gallery:8888/”. What am I missing?
You can take a look at choosing what to display section in docs, there is an example without using LAUNCH_URL (browser automatically detects http server running on port 80)
Thanks, I’ll give it a try to build it. Is build-images.sh is a balenacloud specific convention? I haven’t run into this before.
I tried not setting the LAUNCH_URL to use the automatic detection unsuccessfully. I also tried setting the LAUNCH_URL to “http://hello-world:80/” via the dashboard, and got an error on DNS resolution. It works with “http://localhost:80”. I thought that services in a docker-compose stack like this automatically resolved names in this fashion.
Looking at the docker-compose.yml file that you copy/pasted in your original message, I see that the following lines are commented out:
#expose:
# - "80"
This would explain why the browser block is not automatically detecting the hello-world service on port 80. Can you just confirm if you have tried it with those lines _un_commented?
Nope, doesn’t seem to make a difference. Deployed with those lines un-commented (and no override on LAUNCH_URL in the dashboard), it still fails to resolve “photo-gallery” and shows an error.
Also, the suggestion for how to build the browser image fails with:
start.sh is is from the balenanablocks / browser repo on github
Here’s my current docker-compose.yml. I did eventually figure out how to build browser: the build-images.sh script generates Dockerfiles which I’m using in this most recent iteration. They point to the files in the wrong location “…/” instead of “./” but that’s a simple fix. Note: this still fails with “The site can’t be reached photo-gallery’s server IP address could not be found.”
I’m setting the LAUNCH_URL to http:// followed by what is shown here. The forum won’t let me post the dockerfile with the entire string shown though.
I have checked from a shell on the browser container. The environment variable LAUNCH_URL is still set to the default of “http://photo-gallery:8888/” despite me setting it in the environment: section. Maybe I’m missing something…
Well, I noticed in my docker-compose I had both single and double quotes on the LAUNCH_URL env, but I’ve tried it with either/or and it still doesn’t correctly set the environment variable. That seems like it should be really really simple, but something’s not working.
EDIT: ok, it appears that I had a application level environment variable set in the dashboard which was overriding the value in docker-compose. Name resolution still isn’t working, but if I use “localhost” it’s doing what i expect.
@Ahab well done for figuring it out I suspect the fact you have network_mode: "host" set on your containers is interfering with the name resolution, but it’s also worth mentioning that if you leave LAUNCH_URL blank (it needs to be unset in all contexts), browser will look for services running on port 80 on the device and assume you want to display that if it finds one. So in your case if you remove all settings for LAUNCH_URL, and remove network_mode: "host"from the hello-world container (leave it for browser), it should work in the same way but with less configuration.
Also just as a hint, you can post your docker-compose.yml file using a code block which will keep all of the formatting and allow us to see exactly what you have.
It does appear that removing the network mode from both services, and the LAUNCH_URL environment variable still produces the expected results.
Thanks for the advice on code blocks. Here’s what it looks like currently. TIMEZONE isn’t working, but the way I tried to approach this appears to be debian specific.