Update podman-as-a-replacement-for-docker-desktop.adoc

podman-as-a-replacement-for-docker-desktop.adoc

@@ -36,8 +36,8 @@ Repository: {git-metadata-remotes-origin}[
 GitHub
 ]
 
-Many customers are looking at Podman as a replacement for Docker Desktop now that it is pay to use for businesses.  Many
-of those customers are using Docker Compose and want to continue using it.  This article describes set up of Podman's
+Many businesses are now looking at Podman as a replacement for Docker Desktop now that it is pay to use for businesses.  Many
+of those businesses are using Docker Compose and want to continue using it.  This article describes set up of Podman's
 daemon connection such that Docker Compose can utilize it. This article will also explore some considerations for
 running Podman in a restrictive corporate environment enforced by firewalls and a proxy infrastructure that also uses
 SSL inspection where they resign the traffic with their corporate (self-signed) certificates in order to inspect all
@@ -46,9 +46,10 @@ outbound requests beyond the private security enclave.
 
 == Introduction
 
-This is a shared effort between Henry Hellbusch, Red Hat Senior Consultant, and myself, Red Hat Architect.  Together we
-worked out details of working with Podman to replace Docker Desktop entirely, integrate Docker and Docker Compose with
-Podman and enabled Podman to function in restrictive corporate environments. The original article is available on
+This is a shared effort between Henry Hellbusch, Red Hat Senior Consultant, and Chrisitan Polizzi, Red Hat Architect.  Together we've
+worked out the details of working with Podman to replace Docker Desktop entirely, integrate Docker and Docker Compose with
+Podman and enabled Podman to function in restrictive corporate environments. If you are a Red Hatter with access to the RedHat's Source, 
+the original article is available on 
 https://source.redhat.com/personal_blogs/wip_podman_as_replacement_for_docker_desktop_docker_compose[The Source].
 
 
@@ -86,40 +87,101 @@ same way that docker does.  Instead Podman Compose puts every compose service as
 most part this is compatible with Docker's approach of individual containers.
 
 
+== Exposing the podman remote socket on Linux
+
+Simply enable the podman.socket via systemctl.
+
+[source,bash]
+----
+systemctl --user --now enable podman.socket
+----
+
+And then you can get the path of the socket via 
+
+[source,bash]
+----
+systemctl --user status podman.socket       
+● podman.socket - Podman API Socket
+     Loaded: loaded (/usr/lib/systemd/user/podman.socket; enabled; vendor preset: enabled)
+     Active: active (listening) since Wed 2022-07-20 13:33:00 EDT; 8min ago
+   Triggers: ● podman.service
+       Docs: man:podman-system-service(1)
+     Listen: /run/user/1000/podman/podman.sock (Stream)
+     CGroup: /user.slice/user-1000.slice/user@1000.service/podman.socket
+----
+
+The `listen` line denotes the sock path to use.  
+
 == Configuring Docker and Docker Compose to Utilize the Podman Machine
 
 You can configure the Docker and Docker Compose to interact with the Podman machine. The API exposed by the Podman
 daemon implements the same API as the Docker daemon.  Docker allows you to configure different contexts to point to
-different remote machines.  To utilize the Podman daemon (machine) with Podman 3.x one must create an SSH tunnel to
-point to the Podman API socket (_this is not necessary on Linux hosts_). To do this simply run a command like the
+different remote machines.  
+
+On MacOS, to utilize the Podman daemon (machine) with Podman 3.x one must create an SSH tunnel to
+point to the Podman API socket (NOTE: _this is not necessary on Linux hosts_). To do this simply run a command like the
 following:
 
 [source,bash]
 ----
 ssh -vvv -nNT -L ~/podman.sock:/run/user/1000/podman/podman.sock
 ----
 
-With podman With Podman 4.x one can simply point to the Podman socket without the extra tunnel.  We will cover this in a
+With podman With Podman 4.x one can simply point to the Podman socket without the extra tunnel.  We plan to cover this in a
 future article along with more details and usage surrounding Podman 4.x.
 
-To create the Docker context, run a command like the following:
+To create the Docker context on MacOS, run a command like the following:
 
 [source,bash]
 ----
 docker context create podman \
     --default-stack-orchestrator swarm \
-    --description podman –docker \
+    --description podman --docker \
     host=unix:///Users/shadowman/podman.sock
 ----
 
+Or on Linux:
+
+[source,bash]
+----
+docker context create podman \
+  --default-stack-orchestrator swarm \
+  --description podman --docker \
+  host=unix:///run/user/1000/podman/podman.sock
+----
+
 And then to use the newly created context:
 [source,bash]
 ----
-docker use podman
+docker context use podman
+----
+
+On MacOS, from now on, all *docker* and *docker-compose* commands will utilize the Podman machine for the back end.
+
+On Linux, all *docker* commands will utilize podman for the back end. However, *docker-compose* will continue to 
+default to docker, despite the context setting on docker.  You can specify the context directly with a `--context`
+flag for *docker-compse*.
+
+For example,
+
+[source,bash]
+----
+docker-compose ‐‐context podman up -d
 ----
 
-From now on, all *docker* and *docker-compose* commands will utilize the Podman machine for the back end.
+Or alternatively,
 
+[source,bash]
+----
+DOCKER_HOST="unix:///run/user/1000/podman/podman.sock" docker-compose up -d
+----
+
+Note you could set DOCKER_HOST as an environment variable.
+
+[source,bash]
+----
+export DOCKER_HOST="unix:///run/user/1000/podman/podman.sock"
+----
 
 == Corporate Network Considerations