how to use SSH command line about dip

[jnicho02]

Heh! Typically, i've just answered my own question.

I added openssh-client to my Dockerfile, and '- ~/.ssh:/root/.ssh:ro' to my volumes. I know that it is not ideal to share my .ssh like this, but the Docker images are not going to be published.

Thanks for listening. Dip has been very helpful in my bid to manage chaos and work almost 100% in Docker, keep up the good work.

[bibendi]

Hi Jez!
It seems that I didn't understand your question enough. Please, provide your configs (dip.yml, docker-compose.yml).

dip ssh it's a shourtcut command to run a sidekick container with running ssh-agent which shares SSH_AUTH_SOCK to your main container.

[jnicho02]

I'll try to explain what I want to achieve 👍

• I have a remote Production server that I can ssh into
• I have run ssh-add, so that is uses my credentials to login
• I ssh (and sftp) into the server to dump the Production database, copy the dump file to my local machine, and restore the dump to my dev database
• I wish to do this from within my Docker container (ruby:2.6.6-slim-buster) which does not currently have an 'ssh' command

dip.yml includes the interaction:

interacton:
  livepull:
    description: Pull data from live into development
    service: runner
    command: /bin/bash local_restore.sh

local_restore.sh has the lines:

ssh [email protected] <<EOF
  pg_dump postgres://pg_user:pg_password@localhost:5432/mydb -h localhost --no-acl --no-owner -Fc > mydb_production_$(date +'%Y%m%d').dump
  exit
EOF
sftp [email protected] <<EOF
  get my_db_production_$(date +'%Y%m%d').dump
  exit
EOF
dropdb -h postgres -U postgres my_db_development
createdb -h postgres -U postgres my_db_development
pg_restore -h postgres -U postgres -d my_db_development my_db_production_$(date +'%Y%m%d').dump

Perhaps the SSH that dip has is nothing to do with what I am trying to do? Does 'dip ssh' make it so that you can ssh in to your Docker instance, not out from?

Do you have any pointers? Just install openssh-client?

[blijblijblij]

fyi @jnicho02

alternatively 1

one could do without ssh altogether and lean on the build in postgres container behaviour, from their docs

Initialization scripts

If you would like to do additional initialization in an image derived from this one, add one or more *.sql, *.sql.gz, or *.sh scripts under /docker-entrypoint-initdb.d (creating the directory if necessary). After the entrypoint calls initdb to create the default postgres user and database, it will run any *.sql files, run any executable *.sh scripts, and source any non-executable *.sh scripts found in that directory to do further initialization before starting the service.

Warning: scripts in /docker-entrypoint-initdb.d are only run if you start the container with a data directory that is empty; any pre-existing database will be left untouched on container startup. One common problem is that if one of your /docker-entrypoint-initdb.d scripts fails (which will cause the entrypoint script to exit) and your orchestrator restarts the container with the already initialized data directory, it will not continue on with your scripts.

For example, to add an additional user and database, add the following to /docker-entrypoint-initdb.d/init-user-db.sh:

#!/bin/bash
set -e

psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
    CREATE USER docker;
    CREATE DATABASE docker;
    GRANT ALL PRIVILEGES ON DATABASE docker TO docker;
EOSQL

or

alternatively 2

one can of course also docker exec CONTAINERID COMMAND into the container, or docker-compose exec postgres COMMAND