Não renomeie o fat.jar original em cada servidor.
Se algo tiver que acessar o arquivo com outro nome, crie um link simbólico para o arquivo.
Para serviceA :
ln -s fat.jar a.jar
Para serviceB :
ln -s fat.jar b.jar
Eu tenho mais de 100 microsserviços que são criados primeiro em uma máquina local e depois são sincronizados novamente na máquina de destino e iniciados.
Todos os microservices usam um arquivo fat.jar compartilhado, renomeiam e armazenam em sua pasta de distribuição.
/serviceA
/a.jar
/serviceB
/b.jar
...
Quando nós rsync isso para o servidor, o rsync não vai descobrir que todos os arquivos jar (que juntos representam 99% da distribuição) são exatamente o mesmo fat.jar. Portanto, se o rsync for mais inteligente, ele só poderá transferir um a.jar e depois copiá-lo para todos os outros (já que o tamanho e o hash deles serão exatamente os mesmos).
Isso é possível com o rsync ou procurarei outra solução? Isso pode reduzir significativamente a velocidade de implantação, especialmente quando tenho conectividade fraca com a Internet!
Existem algumas ferramentas de deduplicação que podem fazer isso para você. Se você instalar o zbackup , que provavelmente está disponível como um pacote para o seu sistema, nas máquinas locais e remotas, você poderá alimentá-lo com tar dos seus arquivos e ele irá encontrar as partes que estão duplicadas, e não manter essas cópias.
Você não precisa alterar sua origem, renomeando, vinculando ou vinculando soft. Aqui está um script de exemplo que cria um arquivo grande e o copia para 3 diretórios A, B, C. Ele então divide os diretórios (descompactados) em zbackup . Nós comparamos o tamanho do repositório resultante, e o que seria um tar convencional comprimido. Normalmente, nesse estágio, o repositório agora seria copiado para o controle remoto e descompactado no controle remoto, mas o script apenas o descompacta via tar em um novo diretório para que possamos comparar com o original.
ZB=/tmp/zrepo
cd /tmp/; mkdir try; cd try
dd count=5000 if=/dev/urandom of=file
for dir in A B C
do mkdir $dir
date >$dir/a
cp file $dir/b$dir
done
ls -l /tmp/try/*/*
zbackup init --non-encrypted $ZB
tar cf - A B C | zbackup backup --non-encrypted $ZB/backups/x
du -bs $ZB
tar czf - A B C | wc -c
cd /tmp; mkdir copy; cd copy
zbackup restore --non-encrypted $ZB/backups/x | tar xf -
ls -l /tmp/copy/*/*
Aqui estão algumas das saídas. Como você pode ver, o repositório leva apenas 2632045 bytes, comparado com um tar compactado de 7682010 bytes, mostrando que as 3 cópias do arquivo grande foram desduplicadas para 1 cópia.
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/try/A/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/try/A/bA
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/try/B/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/try/B/bB
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/try/C/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/try/C/bC
4 /tmp/zrepo/info
4 /tmp/zrepo/index/2e0ec29dfd5742005a477525009cfa3a6677f28cffaf2ae5
4 /tmp/zrepo/backups/x
2052 /tmp/zrepo/bundles/e0/e0a14717771602304b480202e05a4f796e8346b7033c231e
2052 /tmp/zrepo/bundles/e0
520 /tmp/zrepo/bundles/3c/3cf381e405fc278c4336ae331c5ea6a9d67b3147792567bc
520 /tmp/zrepo/bundles/3c
2632045 /tmp/zrepo # du -bs of repo
7682010 # size of tar z
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/copy/A/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/copy/A/bA
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/copy/B/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/copy/B/bB
-rw-r--r-- 1 meuh 30 Jun 2 12:35 /tmp/copy/C/a
-rw-r--r-- 1 meuh 2560000 Jun 2 12:35 /tmp/copy/C/bC
sim, é porque você renomeia os arquivos, então é um arquivo diferente a cada vez que o rsync é executado. O rsync não se destina a encontrar duplicatas. É apenas uma ferramenta de cópia de arquivos rápida. Se você estiver ciente dos arquivos que você não copiará várias vezes, basta excluí-los com uma regra de filtro rsync e lidar com isso de uma maneira separada.
Exmpl. rsync -uva --filter "- a.jar" / somedir / / otherdir /, copiará tudo de / somedir para / otherdir exceto a.jar