You've gota device with 16 MiB of flashand you're trying to loada 290 MiB container. I'm guessing it's trying to download the image to the internal flash and failing. You might have to "export" the image using Docker Desktop, upload that to the USB drive thru scp or WinBox, then use the "/container add file=" syntax.

I assume this "disk2" you reference is a USB drive of some type, but I don't see anything that forces RouterOS to use that for downloading the container image.

Hopefully this external drive is a gig or bigger for so piggy a container. It isn't well-optimized. I see Perl and GCC and Git and all kinds of other stuff you don't need running on the final container. Would you care to share the Dockerfile? Maybe we can get it down to something small enough to download into internal flash, then unpack onto your USB drive.

FROM python:3.6 ENV VERSION 0.10.0 RUN mkdir -p /opt/websockify \ && curl -SL https://github.com/novnc/websockify/archive/refs/tags/v$VERSION.tar.gz \ | tar xzC /opt/websockify VOLUME /data EXPOSE 80 EXPOSE 443 WORKDIR /opt/websockify COPY docker-entrypoint.sh / ENTRYPOINT ["/docker-entrypoint.sh"] CMD ["tail -f /dev/null"]

FROM python:3.6

curl -SLhttps://github.com/novnc/websockify/arc ... ION.tar.gz| tar xzC /opt/websockify

Is there another way like a command, code or scheduler where i don t have to reconnect the cable of the external storage and make it automatically to download the container to that external storage?

FROM python:3.6

你的空间问题,在这里:你directly based your container on the flabbybuildpack-depsimage, which accounts foressentially allof the space your container takes. Your actual application adds approximately zilch to the size of the base.

It's fine to use such base layers as-is when deploying to a big old Intel server, but with small RouterOS devices, it's worth learning how to domulti-stage builds苗条基础层的the second stage. You can use tools likeWheelto turn the first-stage version of the application into an independent redistributable package, allowing you to discard the piggy base layer in the second stage.

You can keep using your current "FROM python:3.6" as the first stage, but you then say "FROM debian:stable-slim" (30 MiB) or "FROM alpine" (5 MiB) or "FROM scratch" (0.01 MiB) as the second stage, then unpack your finalized Websockify package atop it.

curl -SLhttps://github.com/novnc/websockify/arc ... ION.tar.gz| tar xzC /opt/websockify

If you're going to start with a full-featured base image like Debian or Buildpack, you might as well use PIP to retrieve your Python deps.

Is there another way like a command, code or scheduler where i don t have to reconnect the cable of the external storage and make it automatically to download the container to that external storage?

Your problem description is hard to parse, but I suspect you can get the automation you need usingSSHscripting, theREST API, orTR-069.

FROM python:3.6 ENV VERSION 0.10.0 RUN mkdir -p /opt/websockify \ && curl -SL https://github.com/novnc/websockify/archive/refs/tags/v$VERSION.tar.gz \ | tar xzC /opt/websockify VOLUME /data EXPOSE 80 EXPOSE 443 WORKDIR /opt/websockify COPY docker-entrypoint.sh / ENTRYPOINT ["/docker-entrypoint.sh"] CMD ["tail -f /dev/null"] FROM alpine:3.14 RUN apk add --no-cache mysql-client ENTRYPOINT ["mysql"]

[admin@DISE_LAB11] > container start 1 [admin@DISE_LAB11] > container shell 1 / # cd opt /opt # ls done [admin@DISE_LAB11] >

i looked in the "opt"-file but nothing is in there.

It would be terrific if you could help me with this projekt I m going on right now.

i looked in the "opt"-file but nothing is in there.

Yes, because you didn't read the multi-stage guide I linked you to above. As formulated, you've thrown the first stage away entirely, replacing it with the second stage. You need at least one "COPY" or "ADD" command in the second stage, referencing the first.

It would be terrific if you could help me with this projekt I m going on right now.

I can advise, but I'm not going to write it for you. You'll have to read the docs I referenced above and work most of this out on your own.

[admin@DISE_LAB11] > container start 0 [admin@DISE_LAB11] > container shell 0 container not running

[admin@DISE_LAB11] > container start 0 [admin@DISE_LAB11] > container shell 0 open: No such file or directory done

i need a python package

Thats why i just installed the alpine container on my pc

i made a repository and pushed the .tar file to the docker hub.

container start 0

i need a python package

That's one way. Another is linked indirectly above,PyInstaller. That packages the Python interpreter, your program, and any modules it requires into a self-contained package you can COPY over from the first-stage build.

This way, you might not even need Alpine as a base. If it will run "FROM scratch" this way, you'll save 5 MiB in your image, minimum. Likely more, since PyInstaller copies over only the parts of the Python runtime it thinks are necessary.

I believe that can be further optimized, because what I see here on a "hello world" program is still fatter than I think it ought to be.

Thats why i just installed the alpine container on my pc

That's the best way anyway. Don't deploy to RouterOS until you get things working under the full-featured container build system. You cause yourself unnecessary pain by shooting straight for the most restrictive environment.

On that same note, starting with a single-stage build is fine. You go with two-stage builds only once you see how fat the result is going to be, then deciding you need to optimize.

i made a repository and pushed the .tar file to the docker hub.

It's 21 MiB, meaning it still won't download to your router's internal flash. I'd try hard to get it under 16 MiB.

我不想说,你不应该运行在external storage, but it's nice to use the internal flash as scratch space for setting up the container.

container start 0

The default "CMD" in that image is "/bin/sh", meaning it will start and then stop, having done nothing useful. Unless you pass cmd="…" to the "/container add" command to override that, that's exactly what you will get.

You should read myContainers Are Not VMsarticle. You appear to be falling into the class of traps it discusses.

#!/bin/bash FROM --platform=linux/arm64/v8 alpine:latest COPY docker-entrypoint.sh / RUN chmod +x docker-entrypoint.sh RUN apk add python3 && apk add py3-pip COPY websockify-0.10.0.zip / ENTRYPOINT ["/docker-entrypoint.sh"] CMD ["tail", "-f", "/dev/null"]

#!/bin/sh mkdir -p /opt/websockify mv websockify-0.10.0.zip /opt/websockify cd /opt/websockify unzip websockify-0.10.0.zip cd websockify-master/ python3 setup.py install tail -f /dev/null

tail -f /dev/null

cmd="tail -f /dev/null"

The following code is the dockerfile...#!/bin/bash

RUN apk add python3 && apk add py3-pip

CMD ["tail", "-f", "/dev/null"]

here is the entrypoint...mv websockify-0.10.0.zip /opt/websockify

The following code is the dockerfile...#!/bin/bash

A Dockerfile isn't a Bash shell script. Itcontainsshell script sections, but it won't run if you say "bash Dockerfile". Drop the shebang line; it makes a counterfactual declaration.

RUN apk add python3 && apk add py3-pip

You shouldn't need that if you're using PyInstaller in this way, with a single-stage build. You have a copy of Python in the installer package, and you no longer need PIP.

You would return to this if doing a two-stage build, creating the installer in the first stage and then using it in the second. The transition from the first stage to the second would throw away the Alpine layer, effectively uninstalling Python and PIP.

CMD ["tail", "-f", "/dev/null"]

You should be running websockify here with the options that cause it to start and keep running. Don't make me research what those are for you. It's your application; you tell me.

here is the entrypoint...mv websockify-0.10.0.zip /opt/websockify

If you're going to do a single-stage build, unpacking websockify is best done in the first stage, baking it into the image, not in the entrypoint, which doesn't run until the container is created from the image. At best, you're unpacking the installer each time you start your container. At worst, you'll cause problems with storage due to the repeated redundant unpacking.

If you take my initial advice and go with a two-stage build, you'd build the package in the first stage, COPY it over from the first to the second stage, unpack there in the second stage, and then run it either via CMD or ENTRYPOINT.

The choice between those two options and whether or not to combine them iscomplicated.

Yes, because you didn't read the multi-stage guide I linked you to above. As formulated, you've thrown the first stage away entirely, replacing it with the second stage. You need at least one "COPY" or "ADD" command in the second stage, referencing the first.





I can advise, but I'm not going to write it for you. You'll have to read the docs I referenced above and work most of this out on your own.

At first thank you for advising me

So I tried some things. I found out that if i want to run websockify on alpine i need a python package and it got more and more complicated. Thats why i just installed the alpine container on my pc instead of the router for test reasons. In that alpine container i connected it to the internet and downloaded websockify and python manually. It is now working on my pc. So i made a repository and pushed the .tar file to the docker hub. You can clickherefor the image in dockerhub. After that I added the container in the hapac2 Router with the "/container remote-image=" syntax. The new problem I get now is that it runs for a short time like milliseconds and stops running.nerdle

It looks like this in the terminal :

Code:Select all

[admin@DISE_LAB11] > container start 0 [admin@DISE_LAB11] > container shell 0 container not running

If I do the commands fast enough the terminal shows me this:

Code:Select all

[admin@DISE_LAB11] > container start 0 [admin@DISE_LAB11] > container shell 0 open: No such file or directory done

What is the thing I m doing wrong? I do not understand why it is working on my pc but not on the router.