Run svc up Automatically During env up

[sprankhub]

Currently, after starting my system, I have to run warden svc up once before I run warden env up, so that my dev environment is correctly started. It is inconvenient having to execute two separate commands. I could probably configure my system to run warden svc up during startup, but this is not really what I would like to do.

I suggest that when warden env up is executed, we check if the warden services are already running. If they are not, then warden svc up should be run automatically.

What do you think?

[ihor-sviziev]

I would say opposite, for instance currently I'm using my own proxy server for proxying traffic that conflicting with traefik global service, but at the same time for m2 project I still could run warden env up and warden shell and run some unit test or some other test that I need without running global services.

Possible options:

• add some parameter to the cli, eg warden env up --with-svc or
• add some env variable to .env file like START_SVC=1
• do not implement this ability at all

[sprankhub]

Interesting, thanks for your input, @ihor-sviziev! In the end, the question is probably how most users use Warden. I assume that it is not that common to run a custom proxy solution and not using Traefik via Warden for this. However, maybe my assumption is wrong.

I still could run warden env up and warden shell and run some unit test or some other test that I need without running global services.

Theoretically, yes, but you need the other services like the DB container for all other test types (integration, MFTF, ...), so I do not consider this a good reason.

add some env variable to .env file like START_SVC=1

I think this would be the best solution, because it is easy to configure and works well for both use cases.

Curious to hear other opinions on this :-)

[ihor-sviziev]

The db container runs as env service, not as global, so it’s not an issue

[davidalger]

The global services which warden svc up starts each have by default a restart policy of always to start automatically whenever the docker daemon restarts. In my experience this has the effect that when a system is booting up, these will automatically come back online. This is the case on my Mac system and on my Fedora system. Haven't tested WSL, but I expect it would be the same, starting when Docker Desktop / WSL starts up.

At the request of a user who specifically did not want this behavior there is a setting WARDEN_RESTART_POLICY was added such that you can put WARDEN_RESTART_POLICY=no in ~/.warden/.env to override that default policy of always but I'm going to assume that is not at play here given the expected behavior, but am curious as it sounds like the restart policy is being ignored or subverted in some way.

What is the scenario in which the containers are failing to come back online? Are they being manually stopped rather than left running? Also for context, what OS / docker version are you running?

I'm hesitant to have env up start global services when run seeing as the restart policy is supposed to address this, but perhaps emitting a warning when they are not running might be appropriate? What are your thoughts on this approach?

Something I've done in per-project bootstrap command on a lot of the M2 projects were I work is this: https://github.com/davidalger/warden-env-magento2/blob/develop/.warden/commands/bootstrap.cmd#L148-L161

[sprankhub]

Thanks @davidalger for the insights! I did not stop anything manually and just shut down my system. After starting it again, I tried to simply run warden env up. Output:

> warden env up
Connecting traefik to shop_default network
Connecting tunnel to shop_default network
Connecting mailhog to shop_default network
Starting shop_db_1            ... done
Starting shop_redis_1         ... done
Starting shop_elasticsearch_1 ... done
Recreating shop_php-fpm_1     ... done
Recreating shop_nginx_1       ... done
Recreating shop_php-debug_1   ... done
Recreating shop_varnish_1     ... done

I tried to open the shop then, but this did not work. Hence, I checked docker ps:

> docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS                    NAMES
bdd6303cd37d        wardenenv/varnish:6.0                  "/bin/sh -c 'envsubs…"   14 seconds ago      Up 13 seconds       80/tcp                   shop_varnish_1
43143576b56b        wardenenv/nginx:1.16                   "/bin/sh -c 'envsubs…"   17 seconds ago      Up 14 seconds       80/tcp                   shop_nginx_1
2b0943e4143c        wardenenv/php-fpm:7.2-magento2-debug   "docker-entrypoint p…"   17 seconds ago      Up 15 seconds       9000/tcp                 shop_php-debug_1
34e717fb42b9        wardenenv/php-fpm:7.2-magento2         "docker-entrypoint p…"   20 seconds ago      Up 17 seconds       9000/tcp                 shop_php-fpm_1
3aabe7371284        wardenenv/elasticsearch:6.8            "/usr/local/bin/dock…"   47 hours ago        Up 20 seconds       9200/tcp, 9300/tcp       shop_elasticsearch_1
c0ee8e6e42ba        wardenenv/redis:4.0                    "docker-entrypoint.s…"   47 hours ago        Up 18 seconds       6379/tcp                 shop_redis_1
cc370c437741        wardenenv/mariadb:10.3                 "docker-entrypoint.s…"   47 hours ago        Up 19 seconds       3306/tcp                 shop_db_1
22d7da02deb9        panubo/sshd:1.1.0                      "/entry.sh /usr/sbin…"   2 days ago          Up 7 hours          127.0.0.1:2222->22/tcp   tunnel
9a84894b2c95        wardenenv/mailhog:1.0                  "MailHog"                2 days ago          Up 7 hours          1025/tcp, 8025/tcp       mailhog
8751e873f478        jpillora/dnsmasq                       "webproc --config /e…"   2 days ago          Up 7 hours          127.0.0.1:53->53/udp     dnsmasq
83c46885abe9        portainer/portainer                    "/portainer"             2 days ago          Up 3 minutes        9000/tcp                 portainer

Then I ran warden svc up and realised that traefik was only started then:

> warden svc up
portainer is up-to-date
dnsmasq is up-to-date
Starting traefik ... 
tunnel is up-to-date
Starting traefik ... done
Connecting traefik to shop_default network
Connecting tunnel to shop_default network
Connecting mailhog to shop_default network

Making a long story short, the automatic restart of traefik did not work. However, I think I know why this is the case: I still have a local Apache running and this prevents traefik from being started correctly. So as soon as I get rid of my local Apache server, everything should work.

Sorry for the confusion :-/ However, having a warning on warden env up when a global service is missing sounds like a great idea to me!

[Skullsneeze]

Another idea would be adding an alias to your system like: alias warden-up='warden svc up && warden env up'

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[sprankhub]

This is more or less still relevant. @davidalger, do you think we should still implement a warning on warden env up when one of the global services is not running?