Tenho mais de 100 microsserviços que são primeiro criados em uma máquina local e depois sincronizados novamente na máquina de destino e iniciados.
Todos os microsserviços usam um arquivo fat.jar compartilhado, renomeiam-no e armazenam em sua pasta de distribuição.
/serviceA
/a.jar
/serviceB
/b.jar
...
Quando sincronizamos novamente com o servidor, o rsync não descobrirá que todos os arquivos jar (que juntos representam 99% da distribuição) são exatamente o mesmo fat.jar. Portanto, se o rsync fosse mais inteligente, ele só poderia transferir um a.jar e 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 devo procurar outra solução? Isso pode reduzir significativamente a velocidade de implantação, especialmente quando tenho pouca conectividade com a Internet!
Responder1
Não renomeie o original fat.jarem cada servidor.
Se algo precisar 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
Responder2
Há algunsdesduplicaçãoferramentas que podem fazer isso por você. Se você instalarzbackup, que provavelmente está disponível como um pacote para o seu sistema, nas máquinas locais e remotas, você pode alimentá-lo com um tardos seus arquivos e ele encontrará as partes que estão duplicadas, e não manterá essas cópias.
Você não precisa alterar sua fonte, renomeando, vinculando fisicamente ou vinculando suavemente. Aqui está um exemplo de script que cria um arquivo grande e o copia para 3 diretórios A, B, C. Em seguida, ele transforma os diretórios (descompactados) em zbackup. Comparamos o tamanho do resultadorepositório, e o que seria um alcatrão comprimido convencional. Normalmente, neste estágio, o repositório 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 alguns dos resultados. Como você pode ver, o repositório ocupa apenas 2.632.045 bytes, em comparação com um tar compactado de 7.682.010 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
Responder3
sim, é porque você renomeia os arquivos, então é um arquivo diferente a cada vez para o rsync. O rsync não se destina a encontrar duplicatas. É apenas uma ferramenta rápida de cópia de arquivos. Se você estiver ciente dos arquivos que não copiará várias vezes, apenas exclua-os com uma regra de filtro rsync e lide com isso de maneira separada.
Exemplo. rsync -uva --filter "- a.jar" /somedir/ /otherdir/, copiará tudo de /somedir para /otherdir exceto a.jar