ssh -p 2222 cas.run help
ssh -p 2222 cas.run help
ssh -p 2222 cas.run help
# ssh -p 2222 cas.run help
The authenticity of host '[cas.run]:2222 ([139.180.180.214]:2222)' can't be established.
RSA key fingerprint is SHA256:i5txciMMbXu2fbB4w/vnElNSpasFcPP9fBp52+Avdbg.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[cas.run]:2222' (RSA) to the list of known hosts.
abucci@cas.run: Permission denied (publickey).
ssh command you posted verbatim!
It's nice you got it hosted rn :), I might try it later on another host where I probably have docker,
(I don't have docker on my local computer, so I will probably install docker on a VM, and copy the shell script, and try to use the docker command to run machines on the other host, (would that work?))
Also, do you mind if I try to break outside of the docker daemon?, (If I were to get out of the docker daemon, I would inform you privately on how so you can fix it properly)
podman compatible and uses the same Docker API? π€ I'm not sure myself.In terms of breaking it, yes please, by all means, do try and of course let me know. I'm not sure how good any of this is just yet... Still seeing what's possible. I'm actually trying to set-up some ingress and default routing so folks _could_ host simple stuff. Tricky to get right π
podman compatible and uses the same Docker API? π€ I'm not sure myself.In terms of breaking it, yes please, by all means, do try and of course let me know. I'm not sure how good any of this is just yet... Still seeing what's possible. I'm actually trying to set-up some ingress and default routing so folks _could_ host simple stuff. Tricky to get right π
podman compatible and uses the same Docker API? π€ I'm not sure myself.In terms of breaking it, yes please, by all means, do try and of course let me know. I'm not sure how good any of this is just yet... Still seeing what's possible. I'm actually trying to set-up some ingress and default routing so folks _could_ host simple stuff. Tricky to get right π
> Podman commands are fully compatible with Docker, so you can replace one with the other: alias docker=podman . The core Podman runtime environment can only run on Linux operating systems. However, you can use a remote client for other operating systems to manage containers on the machine running Podman.12 Apr 2023=
> Podman commands are fully compatible with Docker, so you can replace one with the other: alias docker=podman . The core Podman runtime environment can only run on Linux operating systems. However, you can use a remote client for other operating systems to manage containers on the machine running Podman.12 Apr 2023=
> Podman commands are fully compatible with Docker, so you can replace one with the other: alias docker=podman . The core Podman runtime environment can only run on Linux operating systems. However, you can use a remote client for other operating systems to manage containers on the machine running Podman.12 Apr 2023=
podman "just works"β’ awesome π
podman "just works"β’ awesome π
podman "just works"β’ awesome π
ssh -p 2222 GITHUB_USERNAME@cas.run help but that gives the same error. There's something missing here.
https://github.com/${GITHUB_USER}.keys return keys for you? That's what its using to do auth right now.
https://github.com/${GITHUB_USER}.keys return keys for you? That's what its using to do auth right now.
https://github.com/${GITHUB_USER}.keys return keys for you? That's what its using to do auth right now.
Turns out I thought I had an SSH key set up in github, but github didn't agree with me. So, I re-added the key.
I also had to modify the command slightly to:
ssh -p 2222 -i PRIVATE_GITHUB_KEY GITHUB_USERNAME@cas.run help
since I generate app-specific keypairs and need to specify that for
ssh and I haven't configured it to magically choose the key so I have to specify it in the command line.Anyhow, that did it. Thanks!
$ ssh -p 2222 -i PRIVATE_GITHUB_KEY GITHUB_USERNAME@cas.run add | sh
sh: 135: docker: not found
The quickstart says:
## Quick Start
ssh -p 2222 cas.run add | sh
so that's why I tried this command (I had to modify it with my key and username like before)
Edit: π€¦ββ and that's becasue I don't have
docker on this machine. Sorry about that.
$ ssh -p 2222 -i PRIVATE_GITHUB_KEY GITHUB_USERNAME@cas.run add | sh
sh: 135: docker: not found
The quickstart says:
## Quick Start
ssh -p 2222 cas.run add | sh
so that's why I tried this command (I had to modify it with my key and username like before)
$ ssh -p 2222 -i PRIVATE_GITHUB_KEY GITHUB_USERNAME@cas.run add | sh
sh: 135: docker: not found
The quickstart says:
## Quick Start
ssh -p 2222 cas.run add | sh
so that's why I tried this command (I had to modify it with my key and username like before)
Edit: π€¦ββ and that's becasue I don't have
docker on this machine. Sorry about that, false alarm.
docker CLI. You don't obviously need to have anything else but the CLI to use it as the containers are running remote form you. The install of the CLi is pretty quick 'n easy on most (_if not all?_) systems._
docker CLI. You don't obviously need to have anything else but the CLI to use it as the containers are running remote form you. The install of the CLi is pretty quick 'n easy on most (_if not all?_) systems._
docker CLI. You don't obviously need to have anything else but the CLI to use it as the containers are running remote form you. The install of the CLi is pretty quick 'n easy on most (_if not all?_) systems._
https://cas.run/
https://cas.run/
https://cas.run/
It looks like there's a
podman issue for adding the context subcommand that docker has. Currently podman does not have this subcommand, although this comment has a translation to podman commands that are similar-ish.It looks like that's all you need to do to support
podman right now! Though I'm not 100% sure the containers I tried really are running remotely. Details below.I manually edited the shell script that
cas.run add returns, changing all the docker commands to podman commands. Specifically, I put alias docker=podman at the top so the check for docker would pass, and then I replaced the last two lines of the script with these:
podman system connection add cas "host=tcp://cas.run..."
podman system connection default cas
(that ... after
cas.run is a bunch of connection-specific stuff)I ran the script and it exited with no output. It did create a connection named "cas", and made that the default. I'm not super steeped in how
podman works but I believe that's what you need to do to get podman to run containers remotely.I ran some containers using
podman and I *think* they are running remotely but I don't know the right juju to verify. It looks right though!This means you could probably make minor modifications to the generated shell script to support
podman. Maybe when the check for docker fails, check for podman, and then later in the script use the podman equivalents to the docker context commands.
It looks like there's a
podman issue for adding the context subcommand that docker has. Currently podman does not have this subcommand, although this comment has a translation to podman commands that are similar-ish.It looks like that's all you need to do to support
podman right now! Details follow.I manually edited the shell script that
cas.run add returns, changing all the docker commands to podman commands. Specifically, I put alias docker=podman at the top so the check for docker would pass, and then I replaced the last two lines of the script with these:
podman system connection add cas "host=tcp://cas.run..."
podman system connection default cas
(that ... after
cas.run is a bunch of connection-specific stuff)I ran the script and it exited with no output. It did create a connection named "cas", and made that the default. I'm not super steeped in how
podman works but I believe that's what you need to do to get podman to run containers remotely.I ran some containers using
podman and I *think* they are running remotely but I don't know the right juju to verify. It looks right though!This means you could probably make minor modifications to the generated shell script to support
podman. Maybe when the check for docker fails, check for podman, and then later in the script use the podman equivalents to the docker context commands.
It looks like there's a
podman issue for adding the context subcommand that docker has. Currently podman does not have this subcommand, although this comment has a translation to podman commands that are similar-ish.I manually edited the shell script that
cas.run add returns, changing all the docker commands to podman commands. Specifically, I put alias docker=podman at the top so the check for docker would pass, and then I replaced the last two lines of the script with these:
podman system connection add cas "host=tcp://cas.run..."
podman system connection default cas
(that ... after
cas.run is a bunch of connection-specific stuff)I ran the script and it exited with no output. It did create a connection named "cas", and made that the default. I'm not super steeped in how
podman works but I believe that's what you need to do to get podman to run containers remotely.I ran some containers using
podman and I *think* they are running remotely but I don't know the right juju to verify. It looks right though!This means you could probably make minor modifications to the generated shell script to support
podman. Maybe when the check for docker fails, check for podman, and then later in the script use the podman equivalents to the docker context commands.
It looks like there's a
podman issue for adding the context subcommand that docker has. Currently podman does not have this subcommand, although this comment has a translation to podman commands that are similar-ish.I manually edited the shell script that
cas.run add returns, changing all the docker commands to podman commands. Specifically, I put alias docker=podman at the top so the check for docker would pass, and then I replaced the last two lines of the script with these:
podman system connection add cas "host=tcp://cas.run..."
podman system connection default cas
(that ... after
cas.run is a bunch of connection-specific stuff)I ran the script and it exited with no output. It does seem to have created a connection named "cas".
I can run containers using
podman and I *think* they are running remotely but I don't know the right juju to verify. It looks right though!This means you could probably make minor modifications to the generated shell script to support
podman. Maybe when the check for docker fails, check for podman, and then later in the script use the podman equivalents to the docker context commands.
alias docker=podman, but cannot use podman as a "client" to a remote Docker API engine π’
alias docker=podman, but cannot use podman as a "client" to a remote Docker API engine π’
alias docker=podman, but cannot use podman as a "client" to a remote Docker API engine π’
> I ran some containers using podman and I think they are running remotely but I donβt know the right juju to verify. It looks right though!
Let me check...
> I ran some containers using podman and I think they are running remotely but I donβt know the right juju to verify. It looks right though!
Let me check...
> I ran some containers using podman and I think they are running remotely but I donβt know the right juju to verify. It looks right though!
Let me check...
podman is definitely capable of it. I've never used those features though so I'd have to play around with it awhile to understand how it works and then maybe I'd have a better idea of whether it's possible to get it to work with cas.run. There's a
podman-specific way of allowing remote container execution that wouldn't be too hard to support alongside docker if you wanted to go that route. Personally I don't use docker--too fat, too corporate. podman is lightweight and does virtually everything I'd want to use docker to do.
root@proxy:~# ls -lah /usr/bin/docker /usr/bin/dockerd
-rwxr-xr-x 1 root root 35M Jul 21 20:35 /usr/bin/docker
-rwxr-xr-x 1 root root 96M Jul 21 20:35 /usr/bin/dockerd
root@proxy:~#
Compared with Podman:
$ ls -lah /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
-r-xr-xr-x 1 prologic admin 39M Jul 21 06:13 /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
As you can see the Docker
docker client (CLI) and the Podman tool is roughly the same "weight".The difference is that Docker is a Server<->Client with a daemon architecture, whereas Podman runs containers directly, which is why only Linux is supported. Podman is a bit like my box project.~
root@proxy:~# ls -lah /usr/bin/docker /usr/bin/dockerd
-rwxr-xr-x 1 root root 35M Jul 21 20:35 /usr/bin/docker
-rwxr-xr-x 1 root root 96M Jul 21 20:35 /usr/bin/dockerd
root@proxy:~#
Compared with Podman:
$ ls -lah /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
-r-xr-xr-x 1 prologic admin 39M Jul 21 06:13 /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
As you can see the Docker
docker client (CLI) and the Podman tool is roughly the same "weight".The difference is that Docker is a Server<->Client with a daemon architecture, whereas Podman runs containers directly, which is why only Linux is supported. Podman is a bit like my box project.~
root@proxy:~# ls -lah /usr/bin/docker /usr/bin/dockerd
-rwxr-xr-x 1 root root 35M Jul 21 20:35 /usr/bin/docker
-rwxr-xr-x 1 root root 96M Jul 21 20:35 /usr/bin/dockerd
root@proxy:~#
Compared with Podman:
$ ls -lah /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
-r-xr-xr-x 1 prologic admin 39M Jul 21 06:13 /opt/homebrew/Cellar/podman/4.6.0/bin/podman-remote
As you can see the Docker
docker client (CLI) and the Podman tool is roughly the same "weight".The difference is that Docker is a Server<->Client with a daemon architecture, whereas Podman runs containers directly, which is why only Linux is supported. Podman is a bit like my box project.~
dockerd is 96M and has to run all the time. You can't use docker without it running, so you have to count both. docker + dockerd is 131M, which is over 3x the size of podman. Plus you have this daemon running all the time, which eats system resources podman doesn't use, *and* docker fucks with your network configuration right on install, which podman doesn't do unless you tell it to.That's way fat as far as I'm concerned.
As far as corporate goes,
podman is free and open source software, the end. docker is a company with a pricing model. It was founded as a startup, which suggests to me that, like almost all startups, they are seeking an exit and if they ever face troubles in generating that exit they'll throw out all niceties and abuse their users (see Reddit, the drama with spyware in Audacity, 10,000 other examples). Sure you can use it free for many purposes, and the container bits are open source, but that doesn't change that it's always been a corporate entity, that they can change their policies at any time, that they can spy on you if they want, etc etc etc.That's way too corporate as far as I'm concerned.
I mean, all of this might not matter to you, and that's fine! Nothing wrong with that. But you can't have an alternate reality--these things I said are just facts. You can find them on Wikipedia or docker.com for that matter.
podman can talk to the Docker Engine API. It's just that the commands sometimes have different names in the podmanverse. I think--never used those features.
$ sh setup.sh
Error: --docker additional options "ca=/Users/prologic/.docker/certs.d/localhost/ca.pem,key=/Users/prologic/.docker/certs.d/localhost/key.pem,cert=/Users/prologic/.docker/certs.d/localhost/cert.pem" not supported
Not support for TLS?
$ sh setup.sh
Error: --docker additional options "ca=/Users/prologic/.docker/certs.d/localhost/ca.pem,key=/Users/prologic/.docker/certs.d/localhost/key.pem,cert=/Users/prologic/.docker/certs.d/localhost/cert.pem" not supported
Not support for TLS?
$ sh setup.sh
Error: --docker additional options "ca=/Users/prologic/.docker/certs.d/localhost/ca.pem,key=/Users/prologic/.docker/certs.d/localhost/key.pem,cert=/Users/prologic/.docker/certs.d/localhost/cert.pem" not supported
Not support for TLS?
prologic@JamessMacStudio
Tue Aug 08 01:20:43
~/Projects/docker-proxy
(main) 0 0
$ podman context list
Name URI Identity Default
localhost tcp://localhost:2376 true
prologic@JamessMacStudio
Tue Aug 08 01:20:57
~/Projects/docker-proxy
(main) 0
$ podman --help | grep id
--identity string path to SSH identity file, (CONTAINER_SSHKEY)
I was never able to get the SSH version of the intercepting proxy working. I spent a couple of years on/off trying to get it to work, but there are limitations with the standard library and/or the ssh library or something that prevented the SSH Proxy from fully working See Issue #2 which I've now closed as "won't fix".
I guess Podman needs to learn how to do TLS?
prologic@JamessMacStudio
Tue Aug 08 01:20:43
~/Projects/docker-proxy
(main) 0 0
$ podman context list
Name URI Identity Default
localhost tcp://localhost:2376 true
prologic@JamessMacStudio
Tue Aug 08 01:20:57
~/Projects/docker-proxy
(main) 0
$ podman --help | grep id
--identity string path to SSH identity file, (CONTAINER_SSHKEY)
I was never able to get the SSH version of the intercepting proxy working. I spent a couple of years on/off trying to get it to work, but there are limitations with the standard library and/or the ssh library or something that prevented the SSH Proxy from fully working See Issue #2 which I've now closed as "won't fix".
I guess Podman needs to learn how to do TLS?
prologic@JamessMacStudio
Tue Aug 08 01:20:43
~/Projects/docker-proxy
(main) 0 0
$ podman context list
Name URI Identity Default
localhost tcp://localhost:2376 true
prologic@JamessMacStudio
Tue Aug 08 01:20:57
~/Projects/docker-proxy
(main) 0
$ podman --help | grep id
--identity string path to SSH identity file, (CONTAINER_SSHKEY)
I was never able to get the SSH version of the intercepting proxy working. I spent a couple of years on/off trying to get it to work, but there are limitations with the standard library and/or the ssh library or something that prevented the SSH Proxy from fully working See Issue #2 which I've now closed as "won't fix".
I guess Podman needs to learn how to do TLS?
podman works with TLS. It does not have the "--docker" siwtch so you have to remove that and use the exact replacement commands that were in that github comment.
docker stack deploy -c jmlj.yml jlmjWhere
jmlj.yml is:l
---
version: "3.8"
services:
prologic:
image: r.mills.io/prologic/zs
networks:
- traefik
deploy:
mode: replicated
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.http.services.prologic.loadbalancer.server.port=8000"
resources:
reservations:
memory: 16M
limits:
memory: 32M
restart_policy:
condition: any
networks:
traefik:
external: true
docker stack deploy -c jmlj.yml jlmjWhere
jmlj.yml is:l
---
version: "3.8"
services:
prologic:
image: r.mills.io/prologic/zs
networks:
- traefik
deploy:
mode: replicated
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.http.services.prologic.loadbalancer.server.port=8000"
resources:
reservations:
memory: 16M
limits:
memory: 32M
restart_policy:
condition: any
networks:
traefik:
external: true
docker stack deploy -c jmlj.yml jlmjWhere
jmlj.yml is:l
---
version: "3.8"
services:
prologic:
image: r.mills.io/prologic/zs
networks:
- traefik
deploy:
mode: replicated
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.http.services.prologic.loadbalancer.server.port=8000"
resources:
reservations:
memory: 16M
limits:
memory: 32M
restart_policy:
condition: any
networks:
traefik:
external: true
http://jmlj.cas.run pinting at this service.
http://jmlj.cas.run pinting at this service.
http://jmlj.cas.run pinting at this service.
https://hello-prologic.cas.run/
Which was just spun up using:
$ docker service create --name hello --network traefik --label traefik.enable=true --label traefik.http.services.hello.loadbalancer.server.port=80 nginxdemos/hello
It gets a bit weird when you do this in a Docker Stack using
docker stack deploy though π€£ e.g: https://prologic-prologic-prologic.cas.run/Still trying to figure out the best default routing rule for the ingress proxy to make things easy.
https://hello-prologic.cas.run/
Which was just spun up using:
$ docker service create --name hello --network traefik --label traefik.enable=true --label traefik.http.services.hello.loadbalancer.server.port=80 nginxdemos/hello
It gets a bit weird when you do this in a Docker Stack using
docker stack deploy though π€£ e.g: https://prologic-prologic-prologic.cas.run/Still trying to figure out the best default routing rule for the ingress proxy to make things easy.
https://hello-prologic.cas.run/
Which was just spun up using:
$ docker service create --name hello --network traefik --label traefik.enable=true --label traefik.http.services.hello.loadbalancer.server.port=80 nginxdemos/hello
It gets a bit weird when you do this in a Docker Stack using
docker stack deploy though π€£ e.g: https://prologic-prologic-prologic.cas.run/Still trying to figure out the best default routing rule for the ingress proxy to make things easy.