Jump to content

Docker


Luke

Recommended Posts

I understand the extra subfolder. The issue was it's giving me a double path substitution.

 

"/metadata" substituted to "\\Tower\metadata" was showing up in my nfos as "\\Tower\metadata\\Tower\metadata\..."

Link to comment
Share on other sites

anderbytes

What do you mean substituted? where is this substitution set up?

He must be talking about the volume mapping in Docker (Host -> Guest)
Link to comment
Share on other sites

I'm talking about the optional Network location beneath where you can enter the custom metadata location in the Emby UI. Just like for any other Library path.

 

I don't have the emby in front of me right now, but off the top of my head... Library -> Metadata??

 

Perhaps the Emby code is doing a "replaceAll" vs a "replaceFirst" when plugging that Network location over the local path?

 

"/metadata/metadata" ending up as "substitution/substitution" instead of "substitution/metadata"

 

Or have I just confused things more... I can grab screenshots when i get home if it helps.

Edited by NNate
Link to comment
Share on other sites

skurvy_pirate

I just put together a new server and installed Ubuntu and Docker. I want to get Emby up and running in a container but I am having some troubles getting it to autostart with systemd. I have run:

docker run -it --rm -v /etc/systemd/system:/target \
   emby/embyserver instl service

and then:

sudo systemctl enable embyserver@${USERNAME}

but I get "Failed to execute operation: No such file or directory". There is no emby file in /etc/systemd/system either. So I am not sure where it is going wrong. It looks like the instl service command executes fine as far as I can tell:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-conf-onetime: executing... 
[cont-init.d] 01-conf-onetime: exited 0.
[cont-init.d] 02-user-onetime: executing... 
[cont-init.d] 02-user-onetime: exited 0.
[cont-init.d] 03-upgrade-onetime: executing... 
[cont-init.d] 03-upgrade-onetime: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
instl exited 0
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

 

 

Link to comment
Share on other sites

hurricanehrndz

There is a setup portion for the volumes, you need to run the wrapper script first without systemd

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

skurvy_pirate

I think I have done that. I specified the volumes and they are there in .emby-server.volumes and my Emby server is up and running fine. I think I am missing something else or missed a step.

Link to comment
Share on other sites

hurricanehrndz

Can you verify that embysever@service file exists in /etc/system/systemd

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

skurvy_pirate

Can you verify that embysever@service file exists in /etc/system/systemd

 

Sent from my ONEPLUS A3000 using Tapatalk

 

Sorry I forgot to mention that, it does not. I am not sure why it isn't getting created with the instl service command. 

Link to comment
Share on other sites

Oh, cool. I will look into it and try and find a solution. You can find the template here for now https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base/root/var/cache/systemd

 

Sent from my ONEPLUS A3000 using Tapatalk

 

 

I had the same problem. It looks like you have a typo in your install script.

 

The service file in cache folder is named template@service, but in the install script, you are calling template@.service.

if [[ -z "$1" ]]; then
  install_app
else
  if [[ "$1" -eq "service" ]]; then
    if [[ -f /var/cache/systemd/template@.service ]]; then
      install_service
    fi
  fi
fi

Another thing: do you think it would be better to update the container as well when issuing emby-server update? Right now, if a new version is released and you update it via emby-server update, emby will get updated, but on the next restart of the container, it will revert back to old version. I'm not sure if this is intended to work that way or not. In some cases, if there are breaking changes between version changes, this can lead to non-working emby after container restart.

 

How often are new containers build on Docker Hub? 3.2.1 is already out, but the last stable container was build 5 days ago with 3.2.0. Do you manually run the build command or is that automatic?

Edited by matejz
Link to comment
Share on other sites

hurricanehrndz

The builds are automatic, it should have already been built. Thank you for reporting the issue. I think there is also a flag to enable updates on start.

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

Is a new version is built when new version is released on GitHub? If that is the case, then maybe the new package wasn't in the repo yet when docker container was built?

 

There is an option to set EDGE parameter to 1, for docker to update the container on start. This and with docker container rebuild process working, I think we are covered. We can update current instances for testing with 'emby-server update' and update the container with 'docker pull' for permanent upgrade.

Link to comment
Share on other sites

hurricanehrndz

Yes and no, the chain of build processes is triggered when the GitHub release occurs

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

skurvy_pirate

I have another question related to upgrading Emby. I am still new to Docker and learning so I might be missing something, but I thought upgrading the image and then restarting the container would upgrade the Emby container. I looked at the documentation and running:

docker pull emby/embyserver

Says I have the latest version, but after stopping and starting emby-server, it is still on version 3.2.0.0. If I run:

emby-server update

It will update my Emby instance in the container to 3.2.1.0, but after restarting the container or machine, it reverts back to 3.2.0.0. I know that I can set the EDGE parameter so that the container updates on start, but I thought if the image was updated, it should be running from that image? What am I missing? Also, what is the best practice here? Updating the image, or setting EDGE variable to 1? I feel like to be more Docker-like, updating the image should be the route to go.

Edited by skurvy_pirate
Link to comment
Share on other sites

hurricanehrndz

Updating the image would be the best, unfortunately the last autobuild failed and I have been to sick to do a manual build. I will try and get something going tonight. Our build system will be overhauled soon.

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

Yes and no, the chain of build processes is triggered when the GitHub release occurs

 

Sent from my ONEPLUS A3000 using Tapatalk

 

 

So it's possible when a new release is out, packages are not yet available, so docker builds with the old packages in this case? 

Link to comment
Share on other sites

hurricanehrndz

The way the build system is designed no. Sometimes though the docker build service just has build failures for no apparent reason.

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

hurricanehrndz

So packages are available but for whatever no good reason thr hub labels the build as a failure and then doesn't publish the builds.

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

hurricanehrndz

Yeah it's really frustrating and stupid. We will switching to local builds and will then proceed to push the builds on the hub ourselves soon

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

Smart:)

 

Docker is a really nice solution for things like that, until you need some firewalling in front and you don't have a designated appliance in front of it. I was forced to ditch the solution, because securing it with iptables is just... ugh, no good solution.. 

Link to comment
Share on other sites

skurvy_pirate

Updating the image would be the best, unfortunately the last autobuild failed and I have been to sick to do a manual build. I will try and get something going tonight. Our build system will be overhauled soon.

 

Sent from my ONEPLUS A3000 using Tapatalk

 

Oh ok, so I do have the latest Docker image, but it is just still 3.2.0.0? That makes sense why it wasn't behaving as I expected. Is there a way to label or see what build is included in the Docker image?

Link to comment
Share on other sites

hurricanehrndz

In the future we can definitely label, right now the only way is to look at the build log on the hub

 

Sent from my ONEPLUS A3000 using Tapatalk

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...