O executável do Docker não carrega aliases

3

Eu tenho um alias de bash carregado em um contêiner do Docker, em /etc/bash.bashrc . Funciona como um atalho para um script PHP de linha de comando. Isso é conveniente, pois qualquer um pode usar esse alias diretamente depois de um login no contêiner, com:

$ docker exec -it my-container bash

No entanto, eu também gostaria de poder usar esse alias em comandos únicos sem fazer login, como:

$ docker exec -it my-container my-alias

Eu tentei diferentes variações, como definir o alias em outros lugares além de /etc/bash.bashrc , mas continuo com esse erro:

erro de rpc: code = 2 desc = oci erro de execução: exec failed: exec: "my-alias": arquivo executável não encontrado em $ PATH

Outras sugestões que eu encontrei na web não fizeram o truque, até agora. Alguém?

    
por David Spreekmeester 11.07.2016 / 11:11

4 respostas

2

Não devido a limitações devido ao uso de aliases para uso interativo. Você provavelmente pode hackear isso, mas a solução mais fácil é, de longe, simplesmente transformar seu "alias" em um script e colocá-lo em /bin .

Dockerfile

RUN echo '#! /bin/sh'                >> /bin/mycommand
RUN echo 'echo "running mycommand!"' >> /bin/mycommand
RUN chmod u+x /bin/mycommand

Então funciona como esperado

docker exec -it f3a34 mycommand # => running mycommand!
    
por 15.05.2017 / 19:39
0

Levei uma abordagem ligeiramente diferente, porque não consegui fazer com que funcionasse com a estratégia bash.bashrc . @joat está certo, um alias é provavelmente uma combinação infeliz com a execução parcial de uma linha de comando (com docker exec ).

No final, eu injetei um script (no meu caso através do PHP Composer) na imagem. No meu caso, montando meu diretório local, embora isso não deva importar. Então eu adiciono o caminho para este script no meu Dockerfile através de uma variável de ambiente:

ENV PATH $PATH:./vendor/bin

Isso torna o script globalmente disponível em tempo de execução.

Eu considero uma solução alternativa, ainda, tão interessado em ouvir de qualquer pessoa que tenha aliases regulares para trabalhar em docker exec runtime.

    
por 05.12.2016 / 17:05
0

Eu tive esse problema e resolvi isso colocando o comando que queria executar dentro de um shell temporário, no exemplo que você tem, seria feito assim:

$ docker exec -it my-container sh -l -c "my-alias"

(o -l flag só é necessário se seus aliases estiverem disponíveis apenas em shells de login, que é o meu caso)

Isso torna mais detalhado, mas você sempre pode criar um alias ou uma função para quebrar isso.

    
por 10.05.2018 / 09:59
0

Os aliases são mais úteis quando você deseja encurtar parte de um comando comumente usado que recebe argumentos variáveis. Em um contexto de ruby dev que pode estar criando um alias como

alias be="bundle exec"

porque quem quer digitar bundle exec o tempo todo?

Se o que você realmente quer é uma versão mais curta de um comando mais longo com argumentos estáticos, então você deve criar um script de qualquer maneira. Com um script, ele estará sempre disponível e não dependerá do fornecimento de perfis específicos em contextos específicos (em que basicamente você nunca pode confiar).

Um caso mais comman (como o acima) é quando você usa um alias porque deseja argumentos de cadeia sem esforço até o final do alias. Por exemplo

$ be rails server

ou

$ be rake db:migrate

Em ambos os casos, não quero ter que digitar mais do que preciso. Com apenas uma pitada de bash, no entanto, você pode conseguir a mesma coisa em uma solução mais versátil.

Semelhante a algumas das respostas acima, crie um arquivo - /usr/local/bin/be neste exemplo. Isso pressupõe que /usr/local/bin esteja incluído no seu PATH .

#!/usr/bin/env bash

bundle exec "$@"

seguido com (possivelmente com sudo )

$ chmod +x /usr/local/bin/be

Este é um exemplo ingênuo, e requer que ruby e bundler gem tenham sido instalados, mas o que devemos notar é "$@" , o que nos permite passar um número variável de argumentos para o roteiro. Assim, você obtém a ergonomia do alias, mas com um comando que está sempre disponível e não depende do contexto.

Acho essa abordagem particularmente útil ao trabalhar com contêineres. Espero que ajude.

    
por 05.11.2018 / 04:49