refactor: docker and image changes

Author: neurosnap

.github/workflows/build.yml

@@ -25,10 +25,4 @@ jobs:
       with:
         file: ./Dockerfile
         push: true
-        tags: ghcr.io/picosh/ptun/imgs:latest
-    - name: Build and push
-      uses: docker/build-push-action@v5
-      with:
-        file: ./Dockerfile.autossh
-        push: true
-        tags: ghcr.io/picosh/ptun/autossh:latest
+        tags: ghcr.io/picosh/tunkit/autossh:latest

Dockerfile

@@ -1,13 +1,5 @@
-FROM golang:1.21-alpine
-
-WORKDIR /app
-
-COPY go.* .
-
-RUN go mod download
-
-COPY . .
-
-RUN go build -o docker cmd/docker/main.go
-
-CMD [ "/app/docker" ]
+FROM alpine:3.19
+RUN apk update \
+    && apk add --no-cache autossh ca-certificates bash curl
+COPY entrypoint.sh /entrypoint.sh
+ENTRYPOINT ["/entrypoint.sh"]

Dockerfile.autossh

@@ -6,31 +6,11 @@ lint:
 	golangci-lint run -E goimports -E godot --timeout 10m
 .PHONY: lint
 
-build-example:
-	go build -o ./build/example ./cmd/example
-.PHONY: build
-
-build-docker:
-	go build -o ./build/docker ./cmd/docker
-.PHONY: build-docker
-
-build-pubsub:
-	go build -o ./build/pub ./cmd/pubsub/pub
-	go build -o ./build/sub ./cmd/pubsub/sub
-.PHONY: build-pubsub
-
 tunnel:
-	ssh -L 0.0.0.0:5000:localhost:80 \
+	ssh -L 0.0.0.0:1338:localhost:80 \
 		-p 2222 \
 		-o UserKnownHostsFile=/dev/null \
 		-o StrictHostKeyChecking=no \
 		-N \
 		localhost
 .PHONY: tunnel
-
-tunnel-prod:
-	ssh -L 0.0.0.0:1338:localhost:1338 -N imgs.sh
-	# docker pull ubuntu
-	# docker tag ubuntu localhost:1338/ubuntu
-	# docker push localhost:1338/ubuntu
-.PHONY: tunnel

Makefile

@@ -7,10 +7,10 @@
 # Passwordless authentication
 
 The end-user creates a local forward SSH tunnel to a service running `tunkit`.
-`tunkit` spins up a dedicated web service for that tunnel -- using a unix socket.
-Then the user can access that web service using `localhost`. The web service can
-then access the SSH context in order to know who the user is and what they are
-authorized to do within the web service.
+`tunkit` spins up a dedicated web service for that tunnel -- using a unix
+socket. Then the user can access that web service using `localhost`. The web
+service can then access the SSH context in order to know who the user is and
+what they are authorized to do within the web service.
 
 ## Why?
 
@@ -35,20 +35,26 @@ Use an SSH tunnels for "webhooks":
 
 ## Why?
 
-The biggest benefit is the user's http server is not public.  There's zero
+The biggest benefit is the user's http server is not public. There's zero
 concern for malicious actors or bots trying to hit a user's event endpoints.
-This dramatically reduces the infrastructure requirements for the end-user.
-They just need to start an http server and initial a tunnel to a service.
+This dramatically reduces the infrastructure requirements for the end-user. They
+just need to start an http server and initial a tunnel to a service.
 
-# Development
+# Examples
+
+Checkout our examples folder.
 
 ```bash
-make example
-./build/example
+go run ./cmd/example
 ```
 
 ```bash
-make tunnel
+ssh -L 0.0.0.0:1338:localhost:80 \
+		-p 2222 \
+		-o UserKnownHostsFile=/dev/null \
+		-o StrictHostKeyChecking=no \
+		-N \
+		localhost
 ```
 
-Go to http://localhost:5000
+Go to http://localhost:1338