jonathan-kosgei

I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).

A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.

And it was a dream!

All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.

And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go

jgillman

# Assumes the database container is named 'db'

DOCKER_DB_NAME="$(docker-compose ps -q db)"
DB_HOSTNAME=db
DB_USER=postgres
LOCAL_DUMP_PATH="path/to/local.dump"

docker-compose up -d db
docker exec -i "${DOCKER_DB_NAME}" pg_restore -C --clean --no-acl --no-owner -U "${DB_USER}" -d "${DB_HOSTNAME}" < "${LOCAL_DUMP_PATH}"
docker-compose stop db

milushov

видео уже купили, кто хочет получить доступ, пишите сразу на hl@milushov.ru

видео за 2007-2013 года

---

Если разделить сумму на 10, то по 2.5к руб с носа, но можно больше.

• отправил ли деньги - ✓
• деньги в пути - ➡