diff --git a/.github/workflows/build-and-publish.yml b/.github/workflows/build-and-publish.yml index 03a678eb078..49ec3f02fe1 100644 --- a/.github/workflows/build-and-publish.yml +++ b/.github/workflows/build-and-publish.yml @@ -71,11 +71,12 @@ jobs: run: | community_tag=$( echo ${{ github.ref }} | cut -d'/' -f3 ) hpcc_version=$( echo $community_tag | sed 's/community_//' | sed 's/-[0-9]$//' ) + data="{\"ref\":\"main\", \"inputs\":{ \"hpccVersion\":\"$hpcc_version\",\"hpccSrcBranch\":\"$community_tag\" }}" curl -L \ -X POST \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer ${{ secrets.GAHT_TOKEN }}" \ -H "X-GitHub-Api-Version: 2022-11-28" \ https://api.github.com/repos/xwang2713/github-action-hpcc-terraform/actions/workflows/$WF_YAML_FILE/dispatches \ - -d '{"ref":"main", "inputs": { "hpccVersion":"$hpcc_version", "hpccSrcBranch":"$community_tag" }}' + -d "${data}" diff --git a/devdoc/docs/DocTemplate.md b/devdoc/docs/DocTemplate.md new file mode 100644 index 00000000000..dda60f5bdf9 --- /dev/null +++ b/devdoc/docs/DocTemplate.md @@ -0,0 +1,26 @@ +# Feature Documentation Template +Use this template to create new documentation for a feature, function, or process. Not every feature will require all six sections. Delete the ones that are not applicaple. + +## Overview + +[In this section, provide a brief introduction to the new feature, highlighting its purpose and benefits.] + +## Setup & Configuration + +[If applicable, explain the steps required to set up and configure the new feature, including any dependencies or prerequisites.] + +## User Guide + +[Provide detailed instructions on how to use the new feature, including its functionality, options, and any relevant examples.] + +## API/CLI/Parameter Reference + +[If applicable, document the references for the new feature, including any classes, methods, or parameters.] + +## Tutorial + +[Offer a step-by-step tutorial on how to implement or utilize the new feature, with code snippets or screenshots if appropriate.] + +## Troubleshooting + +[Address common issues or errors that users may encounter while using the new feature, along with possible solutions or workarounds.] diff --git a/docs/EN_US/Installing_and_RunningTheHPCCPlatform/Installing_and_RunningTheHPCCPlatform.xml b/docs/EN_US/Installing_and_RunningTheHPCCPlatform/Installing_and_RunningTheHPCCPlatform.xml index f3f09675266..fa296d24e6e 100644 --- a/docs/EN_US/Installing_and_RunningTheHPCCPlatform/Installing_and_RunningTheHPCCPlatform.xml +++ b/docs/EN_US/Installing_and_RunningTheHPCCPlatform/Installing_and_RunningTheHPCCPlatform.xml @@ -11,7 +11,7 @@ - + @@ -39,26 +39,26 @@ example data used in this manual are fictitious. Any similarity to actual persons, living or dead, is purely coincidental. - + + xmlns:xi="http://www.w3.org/2001/XInclude"/> + xmlns:xi="http://www.w3.org/2001/XInclude"/> HPCC Systems® + xmlns:xi="http://www.w3.org/2001/XInclude"/> - + @@ -99,13 +99,13 @@ - + - + - + We suggest reading this document in its entirety before beginning. The entire process can take an hour or two, depending @@ -115,6 +115,11 @@ + NOTE: This document focuses + primarily on the bare-metal implementation, for cloud and containerized + deployments refer to the Containerized HPCC + Systems® Platform document. + Quick Start Guide @@ -150,7 +155,7 @@ + xmlns:xi="http://www.w3.org/2001/XInclude"/> NOTE: We provide sample scripts (see Appendix:Example @@ -234,7 +239,7 @@ - +
@@ -242,7 +247,7 @@ - +
@@ -381,20 +386,20 @@ sudo yum install -y <hpccsystems platform rpm package> + xmlns:xi="http://www.w3.org/2001/XInclude"/> - + - + + fileref="images/OSSgr3.png"/> There are log files for each component in directories below - + - + + fileref="images/caution.png"/> Your IP address could be different from the ones provided in the example images. Please use the @@ -478,7 +483,7 @@ sudo yum install -y <hpccsystems platform rpm package> + vendor="eclwatchSS"/> @@ -641,14 +646,14 @@ sudo yum install -y <hpccsystems platform rpm package> - + - + + fileref="images/OSSgr3.png"/> You can create a shortcut on your desktop to provide quick access to the ECL IDE. @@ -670,7 +675,7 @@ sudo yum install -y <hpccsystems platform rpm package> - + @@ -708,7 +713,7 @@ sudo yum install -y <hpccsystems platform rpm package> - + @@ -725,7 +730,7 @@ sudo yum install -y <hpccsystems platform rpm package> - + A successful syntax check displays the "No Errors" @@ -743,7 +748,7 @@ sudo yum install -y <hpccsystems platform rpm package> - + The green check mark indicates successful @@ -761,7 +766,7 @@ sudo yum install -y <hpccsystems platform rpm package> - + @@ -801,20 +806,20 @@ sudo yum install -y <hpccsystems platform rpm package> + xmlns:xi="http://www.w3.org/2001/XInclude"/> - + - + + fileref="images/OSSgr3.png"/> You can use this command to confirm HPCC Systems processes are stopped:sudo systemctl status hpccsystems-platform.target @@ -828,8 +833,7 @@ sudo yum install -y <hpccsystems platform rpm package> Start the Configuration Manager service.sudo /opt/HPCCSystems/sbin/configmgr - + @@ -849,7 +853,7 @@ sudo yum install -y <hpccsystems platform rpm package> the wizard, select the Generate new environment using wizard button. - + @@ -883,7 +887,7 @@ sudo yum install -y <hpccsystems platform rpm package> 192.168.55.1-125). IP Addresses can be specified individually using semi-colon delimiters. - + @@ -899,7 +903,7 @@ sudo yum install -y <hpccsystems platform rpm package> Enter the appropriate values as indicated. - + @@ -968,14 +972,14 @@ sudo yum install -y <hpccsystems platform rpm package> - + - + + fileref="images/OSSgr3.png"/> Keep in mind, that your HPPC configuration may be different depending on your needs. For example, you may @@ -991,20 +995,20 @@ sudo yum install -y <hpccsystems platform rpm package> - + - + - + + fileref="images/OSSgr3.png"/> You can resize the Environment Summary by clicking and dragging the lower right corner. @@ -1018,7 +1022,7 @@ sudo yum install -y <hpccsystems platform rpm package> You will now be notified that you have completed the wizard. - + At this point the system has created a file named NewEnvironment.xml in the - + - + + fileref="images/caution.png"/> Be sure system is stopped before attempting to move the environment.xml file. @@ -1064,14 +1068,14 @@ sudo cp /etc/HPCCSystems/source/NewEnvironment.xml /etc/HPCCSystems/environment. - + - + + fileref="images/caution.png"/> Make sure that you have sufficient privileges to write file(s) to the destination directory before @@ -1131,20 +1135,20 @@ sudo cp /etc/HPCCSystems/source/NewEnvironment.xml /etc/HPCCSystems/environment. + xmlns:xi="http://www.w3.org/2001/XInclude"/> - + - + + fileref="images/OSSgr3.png"/> You may want to use a script to push this command out to every node. A sample script is provided @@ -1219,7 +1223,7 @@ sudo /opt/HPCCSystems/sbin/hpcc-push.sh \ + xmlns:xi="http://www.w3.org/2001/XInclude"/> For a CentOS 6 or other System V based systems see Appendix: hpcc-init. @@ -1233,7 +1237,7 @@ sudo /opt/HPCCSystems/sbin/hpcc-push.sh \ + xmlns:xi="http://www.w3.org/2001/XInclude"/> For a CentOS 6 or other System V based systems see Appendix: hpcc-init. @@ -1242,14 +1246,14 @@ sudo /opt/HPCCSystems/sbin/hpcc-push.sh \ - + - + + fileref="images/OSSgr3.png"/> You can use a script to start or stop multiple nodes in the system. See + xmlns:xi="http://www.w3.org/2001/XInclude"/> @@ -1315,11 +1319,11 @@ sudo /opt/HPCCSystems/sbin/hpcc-push.sh \ + xmlns:xi="http://www.w3.org/2001/XInclude"/> + xmlns:xi="http://www.w3.org/2001/XInclude"/> - + - + @@ -2314,7 +2318,7 @@ sudo /etc/init.d/hpcc-init -c esp start + xmlns:xi="http://www.w3.org/2001/XInclude"/> For more information see the Starting-and-stopping the @@ -2676,7 +2680,7 @@ SUM(NOFOLD(s1b + s2b), a); - + Mapping Datatypes @@ -2702,7 +2706,7 @@ SUM(NOFOLD(s1b + s2b), a); https://github.com/hpcc-systems/HPCC-Platform/tree/master/testing/regress/ecl/embedR2.ecl - + diff --git a/docs/PT_BR/ContainerizedHPCC/ContainerizedMods/ConfigureValues.xml b/docs/PT_BR/ContainerizedHPCC/ContainerizedMods/ConfigureValues.xml index 4f37c591c36..87534d39e82 100644 --- a/docs/PT_BR/ContainerizedHPCC/ContainerizedMods/ConfigureValues.xml +++ b/docs/PT_BR/ContainerizedHPCC/ContainerizedMods/ConfigureValues.xml @@ -2,7 +2,7 @@ - Configuração dos Valores + Configuration Values Este capítulo descreve a configuração do HPCC Systems para uma implantação Kubernetes em contêineres. As seções a seguir detalham como as @@ -71,9 +71,10 @@ define quais valores são permitidos e valida o arquivo de valores em relação a eles. Todos os itens principais são declarados no arquivo de esquema, enquanto o arquivo default values.yaml - também contém comentários sobre os elementos mais importantes. Se você - quiser saber quais opções estão disponíveis para qualquer componente - específico, o esquema é um bom lugar para começar. + também contém comentários sobre os elementos mais importantes. + + Se você quiser saber quais opções estão disponíveis para qualquer + componente específico, o esquema é um bom lugar para começar. O arquivo de esquema normalmente contém (para uma propriedade) um nome e uma descrição. Muitas vezes, incluirá detalhes do tipo e os itens @@ -125,7 +126,7 @@ Componentes HPCC Systems e o Arquivo <emphasis>values.yaml</emphasis> - Os chart do Helm do HPCC Systems são enviados com valores de + Os gráficos de Helm do HPCC Systems são enviados com valores de estoque/padrão. Esses charts do Helm têm um conjunto de valores padrão idealmente para serem usados como guia na configuração de sua implantação. Geralmente, cada componente do HPCC Systems é uma lista. Essa lista define @@ -153,19 +154,18 @@ componentes também. Cada componente deve ter uma entrada de recursos, no arquivo - valores.yaml entregues os recursos estão presentes, + values.yaml entregues os recursos estão presentes, mas comentados conforme indicado aqui. #resources: # cpu: "1" # memory: "4G" -O arquivo de valores de estoque funcionará e permitirá que - você mantenha um sistema funcional, porém você deve definir os recursos - dos componentes da maneira que melhor corresponda à sua estratégia - operacional. +The stock values file will work and allow you to stand up a + functional system, however you should define the component resources in + a manner that corresponds best to your operational strategy. - Os serviços do Sistema + Os Serviços do Sistema A maioria dos componentes do HPCC Systems tem uma entrada de definição de serviço, semelhante à entrada de recursos. Todos os @@ -213,7 +213,7 @@ - name: dfuserver maxJobs: 1 - Se você adicionar um mydfuserver da seguinte maneira: + If you were to add a mydfuserver as follows dfuserver: - name: dfuserver @@ -331,11 +331,11 @@ descreva claramente, como thor_50 como no exemplo a seguir. - -name: thor_50 + - name: thor_50 A atualização do valor numWorkers reiniciará o agente Thor ouvindo a fila, fazendo com que todos os - novos jobs usem a nova configuração.3 + novos jobs usem a nova configuração. maxJobs -- Controla o número de jobs, especificamente maxJobs define o número @@ -398,7 +398,7 @@ - Memórias Thor e hThor + Thor e Memória hThor As seções de memory Thor e hThor permitem que a memória de recursos do componente seja refinada em diferentes @@ -443,14 +443,14 @@ da memória com recursos disponíveis deve ser atribuído à memória de consulta e 500M para usos de "thirdParty". - Isso limita o uso de roxiemem de memória do HPCC Systems para - exatamente 3G, deixando 1G livre para outros propósitos. O - "thirdParty" não é realmente alocado, mas é usado apenas como parte do - total em execução, para garantir que a configuração não especifique um - total nesta seção maior que a seção de recursos, por exemplo, se - "thirdParty" foi definido como " 2G" na seção acima, haveria uma - reclamação de tempo de execução quando Thor executasse que a definição - excedeu o limite de recursos. + Isso limita o uso de memória roxiemem do + HPCC Systems a exatamente 3G, deixando 1G livre para outros + propósitos. O "thirdParty" não é realmente alocado, mas é usado + exclusivamente como parte do total em execução, para garantir que a + configuração não especifique um total nesta seção maior do que a seção + de recursos, por exemplo, se "thirdParty" fosse definido como "2G" na + seção acima, haveria uma reclamação de tempo de execução quando o Thor + fosse executado de que a definição excedeu o limite de recurso. Também é possível substituir a porcentagem recomendada padrão (90% por padrão), definindo maxMemPercentage. Se @@ -473,7 +473,7 @@ "consulta" (uso de HPCC roxiemem) e "thirdParty" para todos/qualquer uso de terceiros. É possível que outras categorias sejam adicionadas no futuro, como "python" ou "java" - que definem especificamente os - usos de memória para esses destinos. + usos de memória para esses destinos.. @@ -591,7 +591,7 @@ # pvc: <name> # The name of the persistant volume claim # forcePermissions: false # hosts: [ <host-list> ] # Inline list of hosts - # hostGroup: <name> # Name of the host group for bare metal + # hostGroup: <name> # Name of the host group for bare-metal # # must match the name of the storage plane.. # # Other options: @@ -762,7 +762,16 @@ menores do host ou os mesmos hosts, mas armazenando partes diferentes em nós diferentes, por exemplo: - Group: groupCDE + storage: + hostGroups: + - name: groupABCDE # Explicit list of hosts + hosts: [A, B, C, D, E] + - name groupCDE # Subset of the group last 3 hosts + hostGroup: groupABCDE + count: 3 + offset: 2 + - name groupDEC # Same set of hosts, but different part->host mapping + hostGroup: groupCDE delta: 1 O segundo aspecto é adicionar uma propriedade à definição do @@ -773,7 +782,7 @@ hostGroup: <name> O nome do grupo de hosts para bare metal. O nome do hostGroup deve - corresponder ao nome do plano de armazenamento.. + corresponder ao nome do plano de armazenamento. @@ -796,9 +805,97 @@ prefix: "/home/demo/mydropzone" hosts: [ 'mylandingzone.com' ] # Inline reference to an external host. + + + Armazenamento Remoto + + Você pode configurar sua implantação em nuvem do HPCC Systems + para acessar arquivos lógicos de outros ambientes remotos. Você + configura esse armazenamento remoto adicionando uma seção "remota" ao + seu gráfico de helm. + + A seção storage.remote é uma lista de + ambientes remotos nomeados que definem a URL do serviço remoto e uma + seção que mapeia os nomes dos planos remotos para os nomes dos planos + locais. Os planos locais referenciados são planos especiais com a + categoria 'remoto'. Eles são somente leitura e só estão disponíveis + para os motores que podem lê-los. + + Por exemplo: + + storage: + planes: +... + - name: hpcc2-stddata + pvc: hpcc2-stddata-pv + prefix: "/var/lib/HPCCSystems/hpcc2/hpcc-stddata" + category: remote + - name: hpcc2-fastdata + pvc: hpcc2-fastdata-pv + prefix: "/var/lib/HPCCSystems/hpcc2/hpcc-fastdata" + category: remote + remote: + - name: hpcc2 + service: http://20.102.22.31:8010 + planes: + - remote: data + local: hpcc2-stddata + - remote: fastdata + local: hpcc2-fastdata + + Este exemplo define um alvo remoto chamado "hpcc2" cuja URL do + serviço DFS é http://20.102.22.31:8010 e cujo plano local é + "hpcc2data". O plano local deve ser definido de modo que compartilhe o + mesmo armazenamento que o ambiente remoto. Espera-se que isso seja + feito através de um PVC que foi pré-configurado para usar o mesmo + armazenamento. + + Para acessar o arquivo lógico em ECL use o seguinte + formato: + + ds := DATASET('~remote::hpcc2::somescope1::somelfn1', rec); + + + + Armazenamento Preferêncial + + A opção preferredReadPlanes está disponível + para cada tipo de cluster - hThor, Thor e Roxie. + + Esta opção é significativa apenas para arquivos lógicos que + residem em múltiplos planos de armazenamento. Quando especificado, a + plataforma HPCC Systems buscará ler arquivos do(s) plano(s) + preferido(s) se um arquivo residir neles. Estes planos preferenciais + devem existir e ser definidos em + storage.planes. + + O próximo trecho é um exemplo de um cluster Thor configurado com + a opção preferredDataReadPlanes. + + thor: +- name: thor + prefix: thor + numWorkers: 2 + maxJobs: 4 + maxGraphs: 3 + preferredDataReadPlanes: + - data-copy + - indexdata-copy + + + No exemplo acima, ao executar uma consulta que lê um arquivo que + reside tanto em "data" quanto em "data-copy" (nessa ordem), + normalmente leria a primeira cópia em "data". Com + preferredDataReadPlanes especificado, se esse + arquivo também residir em "data-copy", Thor lerá essa cópia. + + Isso pode ser útil quando existem múltiplas cópias de arquivos + em diferentes planos com características distintas que podem impactar + o desempenho. + - + Itens de armazenamento para componentes de HPCC Systems @@ -835,10 +932,12 @@ Onde as consultas ECL compiladas são armazenadas. O armazenamento precisa permitir que objetos compartilhados sejam - carregados diretamente a partir dele de forma eficiente. Se você - quiser dados Dali e dll no mesmo plano, é possível usar o mesmo - prefixo para ambas as propriedades do subcaminho. Ambos usariam o - mesmo prefixo, mas deveriam ter subcaminhos diferentes. + carregados diretamente a partir dele de forma eficiente. + + Se você quiser dados Dali e dll no mesmo plano, é possível usar + o mesmo prefixo para ambas as propriedades do subcaminho. Ambos + usariam o mesmo prefixo, mas deveriam ter subcaminhos + diferentes. @@ -865,8 +964,76 @@ + + Egresso + + A fim de permitir que os clusters sejam trancados de forma segura, + mas ainda permitir o acesso aos serviços de que precisam, existe um + mecanismo de saída. O egresso fornece um mecanismo similar ao ingresso, + sendo capaz de definir quais endpoints e portas os componentes têm + permissão para se conectar. + + A maioria dos componentes do HPCC Systems possui suas próprias + políticas de rede geradas automaticamente. As políticas de rede geradas + tipicamente trabalham para limitar o ingresso e egresso à comunicação + inter-componente, ou apenas ao ingresso de serviço externo + esperado. + + Por exemplo, em um sistema implantado por padrão com políticas de + rede em vigor, uma consulta em execução (em hThor, Thor ou Roxie) não + será capaz de se conectar com um serviço de terceiros, como um serviço + LDAP ou pilha de log. + + Na configuração padrão, qualquer pod com acesso à API do Kube + também terá acesso a qualquer endpoint externo. Isso ocorre porque uma + NetworkPolicy é gerada para acesso de egresso para + componentes que precisam de acesso à API do Kube. No entanto, + global.egress.kubeApiCidr e + global.egress.kubeApiPort no values.yaml devem ser + configurados em um sistema seguro para restringir esse acesso de + egresso, de modo que ele apenas exponha acesso de egresso para o + endpoint da API do Kube. + + Adicionamos um mecanismo semelhante às definições de visibilidade, + que permite seções de saída nomeadas, que então podem ser referenciadas + por componente. + + Por exemplo: + + global: + egress: + engineEgress: + - to: + - ipBlock: + cidr: 201.13.21.0/24 + - ipBlock: + cidr: 142.250.187.0/24 + ports: + - protocol: TCP + port: 6789 + - protocol: TCP + port: 7890 +... + +thor: +... + egress: engineEgress + + Note que o nome 'engineEgress' é um nome arbitrário, qualquer nome + pode ser escolhido, e qualquer número dessas seções de egresso nomeadas + pode ser definido. + + Para mais informações, por favor, veja a seção + egress: no arquivo YAML padrão fornecido pelo HPCC + Systems. O arquivo values.yaml pode ser encontrado + no diretório helm/hpcc/ no repositório github do HPCC Systems: + + https://github.com/hpcc-systems/HPCC-Platform + + - Valores de Segurança + Valores de segurança Esta seção examinará as seções de values.yaml que tratam dos componentes de segurança do sistema. @@ -956,21 +1123,21 @@ - Visibilities + Visibilidades - A seção Visibilities pode ser usada para definir rótulos, + A seção Visibilidades pode ser usada para definir rótulos, anotações e tipos de serviço para qualquer serviço com a visibilidade especificada. - - Replicas e Resources + + Réplicas e Recursos Outros valores dignos de nota nos charts que têm relação com a instalação e configuração do HPCC Systems. - Replicas + Réplicas replicas: define quantos nós de réplica surgem, quantos pods são executados para equilibrar uma carga. Para ilustrar, se você tiver um @@ -1016,88 +1183,6 @@ peloHPCC Systems. Esses valores são especificados como uma lista de pares de nome-valor, conforme ilustrado abaixo. - - Os taints e as tolerations trabalham juntos para garantir que os - pods não sejam agendados em nós inadequados. As tolerâncias são - aplicadas aos pods e permitem (mas não exigem) que os pods sejam - agendados em nós com taints correspondentes. Taints são o oposto - - elas permitem que um nó repele um conjunto de cápsulas. - - Por exemplo, todos os workers Thor devem estar no tipo - apropriado de VM. Se um grande job de Thor aparecer – então o nível de - taints entra em jogo. - - Para obter mais informações e exemplos de nossos Taints, - Tolerations e Placements, consulte nossa documentação do - desenvolvedor: - - https://github.com/hpcc-systems/HPCC-Platform/blob/master/helm/hpcc/docs/placements.md - - - Placement - - O Placement é responsável por encontrar o melhor nó para um - pod. Na maioria das vezes, o placement é tratado automaticamente - pelo Kubernetes. Você pode restringir um pod para que ele possa ser - executado apenas em um conjunto específico de nós. Usando canais, - você pode configurar o agendador do Kubernetes para usar uma lista - de "pods" para aplicar configurações aos pods. Por exemplo: - - placements: - - pods: [list] - placement: - <supported configurations> - - Os pods: [list] podem conter uma variedade de itens. - - - - Tipos de componentes do HPCC Systems, usando o - tipo de prefixo: pode ser: dali, esp, - eclagent, eclccserver, roxie, thor. Por exemplo - "tipo:esp" - - - - Alvo; o nome de um item de array dos tipos acima usando o - prefixo "target:" Por exemplo "target:roxie" ou - "target:thor". - - - - Pod, nome de metadados "Implantação" do nome do item de - matriz de um tipo. Por exemplo, "eclwatch", "mydali", - "thor-thoragent" - - - - Expressão regular do nome do trabalho: Por exemplo, - "compile-" ou "compile-". ou correspondência exata - "^compile-.$" - - - - Todos: para solicitar todos os componentes do HPCC - Systems. Os canais padrão para os pods que entregamos são - [all] - - - - Placements – no Kubernetes, o - conceito de placement permite distribuir seus pods por tipos de nós - com características particulares. Os placements seriam usados para - garantir que os pods ou trabalhos que desejam nós com - características específicas sejam colocados neles. - - Por exemplo, um cluster Thor pode ser direcionado para machine - learning usando nós com uma GPU. Outro trabalho pode querer nós com - uma boa quantidade de memória ou outro para mais CPU. Você pode usar - posicionamentos para garantir que os pods com requisitos específicos - sejam colocados nos nós apropriados. - - - global: env: - name: SMTPserver @@ -1106,39 +1191,38 @@ A seção global.env do arquivo values.yaml fornecido adiciona variáveis de ambiente padrão para todos os componentes. Você também pode especificar variáveis de ambiente para os componentes individuais. - Consulte o esquema para definir este valor para componentes + Consulte o esquema para definir esse valor para componentes individuais. - Para adicionar valores de ambiente, você pode inseri-los em seu - arquivo YAML de configurações personalizadas ao implantar o HPCC Systems - conteinerizados. Esta solicitação é baseada na conversa anterior. + Para adicionar valores de ambiente, você pode inseri-los no seu + arquivo YAML de configuração de personalização quando fizer o deploy do + seu HPCC Systems contêinerizado. - Variáveis de Ambiente para Sistemas Containerizados + Variáveis de Ambiente para Sistemas Conteinerizados Existem várias configurações em environment.conf para sistemas bare-metal. Embora muitas configurações de environment.conf não sejam válidas para contêineres, algumas podem ser úteis. Em uma implantação - em nuvem, essas configurações são herdadas de variáveis de ambiente. - Essas variáveis de ambiente são configuráveis usando o arquivo yaml - values, seja globalmente ou no nível do componente. + na nuvem, essas configurações são herdadas de variáveis de ambiente. + Essas variáveis de ambiente são configuráveis usando o values yaml + globalmente ou no nível do componente. - Algumas dessas variáveis estão disponíveis para implementações - em contêiner e na nuvem e podem ser definidas usando o chart Helm. Os - seguintes valores de environment.conf para bare-metal têm esses + Algumas dessas variáveis estão disponíveis para implantações em + contêineres e na nuvem e podem ser definidas usando o gráfico do Helm. + Os seguintes valores de environment.conf para sistemas bare-metal têm valores equivalentes que podem ser definidos para instâncias - conteinerizadas. Esta solicitação é baseada na conversa - anterior. + conteinerizadas. - Valor - Environment.conf + Environment.conf + Value - Variavel Helm - Environment + Helm Environment + Variable @@ -1168,8 +1252,8 @@ - O seguinte exemplo configura uma variavel de ambiente para pular - a limpeza do Python no componente Thor: + O seguinte exemplo define a variável de ambiente para pular a + limpeza do Python no componente Thor: thor: env: @@ -1179,28 +1263,28 @@ - Plano de Construção de Index - - Defina o valor indexBuildPlane como uma opção - de chart helm para permitir que os arquivos de índice sejam escritos por - padrão em um plano de dados diferente. Ao contrário de arquivos planos, - arquivos de índices têm requisitos diferentes. Os arquivos de índice se - beneficiam de armazenamento de acesso aleatório rápido. Normalmente, - arquivos planos e arquivos de índice são resultantes para os planos de - dados padrão definidos. Usando esta opção, você pode definir que os - arquivos de índice são construídos em um plano de dados separado de - outros arquivos comuns. Este valor de chart pode ser fornecido em um - nível de componente ou global. - - Por exemplo, adicionando o valor a um nível global sob - global.storage: + Index Build Plane + + Defina o valor indexBuildPlane como uma opção + de gráfico de helm para permitir que arquivos de índice sejam escritos + por padrão em um plano de dados diferente. Ao contrário de arquivos + planos, os arquivos de índices têm requisitos diferentes. Os arquivos de + índice se beneficiam de armazenamento de acesso aleatório rápido. + Normalmente, arquivos planos e arquivos de índices são gravados nos + planos de dados padrão definidos. Usando esta opção, você pode definir + que os arquivos de índice são construídos em um plano de dados separado + de outros arquivos comuns. Este valor de gráfico pode ser fornecido em + um componente ou nível global. + + Por exemplo, adicionando o valor a um nível global em + globlal.storage: global: storage: indexBuildPlane: myindexplane - Opcionalmente, você pode adicioná-lo ao nível do componente, da - seguinte forma: + Optionally, you could add it at the component level, as + follows: thor: - name: thor @@ -1210,8 +1294,8 @@ maxGraphs: 2 indexBuildPlane: myindexplane - Quando este valor é definido no nível do componente, ele sobrepõe - o valor definido no nível global. + Opcionalmente, você poderia adicioná-lo no nível do componente, + conforme segue: @@ -1219,53 +1303,54 @@ Pods e Nós Uma das principais características do Kubernetes é sua capacidade de - agendar pods nos nós do cluster. Um pod é a menor e mais simples unidade - no ambiente do Kubernetes que você pode criar ou implantar. Um nó é uma - máquina "trabalhadora" física ou virtual no Kubernetes. - - A tarefa de agendar pods para nós específicos do cluster é - gerenciada pelo kube-scheduler. O comportamento padrão desse componente é - filtrar os nós com base nas solicitações de recursos e limites de cada - contêiner no pod criado. Nós viáveis são então pontuados para encontrar o - melhor candidato para o posicionamento do pod. O agendador também leva em - conta outros fatores como afinidade e anti-afinidade de pods, taints e - tolerations, restrições de distribuição de topologia de pod e os rótulos - do seletor de nó. O agendador pode ser configurado para usar esses - algoritmos e políticas diferentes para otimizar o posicionamento do pod de + agendar pods nos nós do cluster. Um pod é a unidade mais pequena e simples + no ambiente Kubernetes que você pode criar ou implantar. Um nó é uma + máquina "trabalhadora", física ou virtual, no Kubernetes. + + A tarefa de agendar pods para nós específicos no cluster é + gerenciada pelo kube-scheduler. O comportamento padrão deste componente é + filtrar os nós com base nas solicitações e limites de recursos de cada + recipiente no pod criado. Os nós viáveis são então pontuados para + encontrar o melhor candidato para a localização do pod. O agendador também + leva em conta outros fatores, como afinidade e anti-afinidade de pods, + marcas e tolerâncias, restrições de dispersão de topologia de pod, e os + rótulos de seleção de nó. O agendador pode ser configurado para usar esses + diferentes algoritmos e políticas para otimizar a colocação do pod de acordo com as necessidades do seu cluster. Você pode implantar esses valores usando o arquivo values.yaml ou pode colocá-los em um arquivo e fazer com que o Kubernetes leia os valores - do arquivo fornecido. Consulte a seção acima Técnicas de - Personalização para obter mais informações sobre como - personalizar sua implantação. + do arquivo fornecido. Veja a seção acima Técnicas de + personalização para mais informações sobre como personalizar + sua implantação. Placements - O termo "Placements" é usado pelo HPCC Systems, ao qual o - Kubernetes se refere como scheduler ou agendamento/distribuição. Para - evitar confusão com os termos específicos do scheduler da HPCC Systems e - ECL, referenciaremos o agendamento do Kubernetes como colocações. As - colocações são um valor na configuração do HPCC Systems que está em um - nível acima dos itens, como o nodeSelector, Toleration, Affinity e - Anti-Affinity e TopologySpreadConstraints. - - O placements é responsável por encontrar o melhor nó para um pod. - Na maioria das vezes, o agendamento é realizado automaticamente pelo - Kubernetes. Você pode restringir um Pod para que ele possa funcionar + O termo "Placements" é usado pelo HPCC Systems para descrever o + que o Kubernetes se refere como agendador ou agendamento/atribuição. + Para evitar confusão com a terminologia específica do agendador do HPCC + Systems e ECL, usamos o termo "Placements" para nos referir ao + agendamento do Kubernetes. Os Placements são um valor na configuração do + HPCC Systems que reside em um nível acima de entidades como + nodeSelector, Tolerância, Afinidade e Anti-Afinidade, e + TopologySpreadConstraints. + + O Placement é responsável por encontrar o melhor nó para um pod. + Na maioria das vezes, a colocação é gerenciada automaticamente pelo + Kubernetes. Você pode restringir um Pod para que ele possa ser executado apenas em um conjunto específico de Nós. - Os placements, então, seriam usados para garantir que pods ou jobs - que desejam nós com características específicas sejam colocados nesses + Placements, então, seriam usadas para garantir que pods ou jobs + que requerem nós com características específicas sejam alocados nestes nós. Por exemplo, um cluster Thor poderia ser direcionado para machine - learning usando nós com GPU. Outro job pode querer nós com boa - quantidade de memória ou outro para mais CPU. + learning usando nós com GPU. Outro job pode precisar de nós com uma + quantidade maior de memória ou outro para mais CPU. Usando placements, você pode configurar o agendador do Kubernetes - para usar uma lista de "pods" para aplicar as configurações aos + para usar uma lista de "pods" para aplicar configurações aos pods. Por exemplo: @@ -1276,12 +1361,12 @@ <supported configurations> - Escopo do Placement + Escope do Placement Use padrões de pods para aplicar o escopo para os placements. - Os pods: [list] podem conter o seguinte: + Os pods: [list] podem conter uma variedade de itens. @@ -1291,7 +1376,7 @@ - Type: <component> + Tipo: <component> Cobre todos os pods/trabalhos sob este tipo de componente. Isso é comumente utilizado para os componentes do @@ -1301,7 +1386,7 @@ - Target: <name> + Destino: <name> O campo "name" de cada componente, uso típico para componentes do HPCC Systems refere-se ao nome do cluster. Por @@ -1323,7 +1408,7 @@ - Job name: + Nome do Job: O nome do job é geralmente também uma expressão regular, já que o nome do job é gerado dinamicamente. Por @@ -1360,73 +1445,78 @@ - Node Selection + Seleção de Nós - In a Kubernetes container environment, there are several ways to - schedule your nodes. The recommended approaches all use label selectors - to facilitate the selection. Generally, you may not need to set such - constraints; as the scheduler usually does reasonably acceptable - placement automatically. However, with some deployments you may want - more control over specific pods. + Em um ambiente de contêineres Kubernetes, existem várias maneiras + de agendar seus nós. As abordagens recomendadas utilizam seletores de + rótulos para facilitar a seleção. Geralmente, você pode não precisar + definir tais restrições, pois o agendador normalmente faz um + posicionamento razoavelmente aceitável automaticamente. No entanto, em + algumas implantações, você pode querer ter mais controle sobre pods + específicos. - Kubernetes uses the following methods to choose where to schedule - pods: + O Kubernetes utiliza os seguintes métodos para escolher onde + agendar os pods: - nodeSelector field matching against node labels + campo nodeSelector correspondendo aos rótulos dos nós - Affinity and anti-affinity + Afinidade e anti-afinidade - Taints and Tolerations + Taints and Tolerâncias - nodeName field + campo nodeName - Pod topology spread constraints + restrições de dispersão topológica de pods - Node Labels - - Kubernetes nodes have labels. Kubernetes has a standard set of - labels used for nodes in a cluster. You can also manually attach - labels which is recommended as the value of these labels is - cloud-provider specific and not guaranteed to be reliable. - - Adding labels to nodes allows you to schedule pods to nodes or - groups of nodes. You can then use this functionality to ensure that - specific pods only run on nodes with certain properties. + Rótulo dos Nós + + Os nós do Kubernetes possuem rótulos. Kubernetes possui um + conjunto padrão de rótulos utilizados para nós em um cluster. Você + também pode anexar rótulos manualmente, o que é recomendado, já que o + valor desses rótulos é específico do provedor de nuvem e não é + garantido ser confiável. + + Adicionar rótulos aos nós permite agendar pods para nós ou + grupos de nós específicos. Você pode então usar essa funcionalidade + para garantir que pods específicos sejam executados apenas em nós com + determinadas propriedades. - The nodeSelector - - The nodeSelector is a field in the Pod specification that allows - you to specify a set of node labels that must be present on the target - node for the Pod to be scheduled there. It is the simplest form of - node selection constraint. It selects nodes based on the labels, but - it has some limitations. It only supports one label key and one label - value. If you wanted to match multiple labels or use more complex - expressions, you need to use node Affinity. - - Add the nodeSelector field to your pod specification and specify - the node labels you want the target node to have. You must have the - node labels defined in the job and pod. Then you need to specify each - node group the node label to use. Kubernetes only schedules the pod - onto nodes that have the labels you specify. - - The following example shows the nodeSelector placed in the pods - list. This example schedules "all" HPCC components to use the node - pool with the label group: "hpcc". + O nodeSelector + + O nodeSelector é um campo na especificação do Pod que permite + especificar um conjunto de rótulos de nó que devem estar presentes no + nó de destino para que o Pod seja agendado lá. É a forma mais simples + de restrição de seleção de nó. Ele seleciona nós com base nos rótulos, + mas possui algumas limitações. Suporta apenas uma chave de rótulo e um + valor de rótulo. Se você desejar corresponder a vários rótulos ou usar + expressões mais complexas, precisa usar a Afinidade de Nó (node + Affinity) + + Adicione o campo nodeSelector à especificação do seu pod e + especifique os rótulos de nó que você deseja que o nó de destino + tenha. Você deve ter os rótulos de nó definidos no trabalho (job) e no + pod. Em seguida, você precisa especificar cada grupo de nós que o + rótulo de nó deve usar. O Kubernetes agendará o pod apenas nos nós que + possuem os rótulos que você especificar. + + O exemplo a seguir mostra o nodeSelector colocado na lista de + pods. Este exemplo agenda todos os componentes do HPCC para usar o + grupo de nós com o rótulo "group: hpcc". placements: - pods: ["all"] @@ -1434,16 +1524,16 @@ nodeSelector: group: "hpcc" - Note: The label group:hpcc - matches the node pool label:hpcc. + Nota: O rótulo group:hpcc + corresponde ao rótulo do grupo de nós hpcc. - This next example shows how to configure a node pool to prevent - scheduling a Dali component onto this node pool labelled with the key - spot: via the value false. As this kind of node is not always - available and could get revoked therefore you would not want to use - the spot node pool for Dali components. This is an example for how to - configure a specific type (Dali) of HPCC Systems component not to use - a particular node pool. + Este próximo exemplo mostra como configurar um grupo de nós para + evitar o agendamento de um componente Dali neste grupo de nós rotulado + com a chave spot: com o valor false. Como esse tipo de nó nem sempre + está disponível e pode ser revogado, você não deseja usar o grupo de + nós spot para componentes Dali. Este é um exemplo de como configurar + um tipo específico (Dali) de componente do HPCC Systems para não usar + um determinado grupo de nós. placements: - pods: ["type:dali"] @@ -1451,50 +1541,51 @@ nodeSelector: spot: "false" - Quando se usa nodeSelector, vários nodeSelectors podem ser + Ao usar nodeSelector, múltiplos nodeSelectors podem ser aplicados. Se chaves duplicadas forem definidas, apenas a última - prevalece. + prevalecerá. - Taints e Tolerations + Taints e Tolerâncias - Taints e Tolerations são tipos de restrições de nodes do - Kubernetes também mencionadas como afinidade de nós. Apenas uma - afinidade pode ser aplicada em um pod. Se um pod combinar com várias - listas de 'pods' de placements, então apenas a última definição de + Taints e Tolerâncias são tipos de restrições de nó do + Kubernetes, também referidas como Afinidade de Nó. Apenas uma + afinidade pode ser aplicada a um pod. Se um pod corresponder a várias + listas de posicionamento ('pods'), então apenas a última definição de afinidade será aplicada. - Taints e tolerations trabalham juntos para garantir que os pods - não sejam agendados em nós inadequados. Tolerations são aplicadas aos + Taints e tolerâncias trabalham juntos para garantir que os pods + não sejam agendados em nós inadequados. Tolerâncias são aplicadas aos pods e permitem (mas não exigem) que os pods sejam agendados em nós - com taints correspondentes. Taints são o oposto - eles permitem que um - nó repila um conjunto de pods. Uma maneira de implantar usando taints, - é configurar para repelir todos, exceto um nó específico. Então, esse - pod pode ser agendado em outro nó que é tolerante. + com taints correspondentes. Taints funcionam de forma oposta - elas + permitem que um nó repila um conjunto de pods. Uma forma de implantar + usando taints é configurar para repelir todos os nós exceto um + específico. Então, esse pod pode ser agendado em outro nó que seja + tolerante. - Por exemplo, os jobs Thor devem estar todos no tipo apropriado - da VM. Se um job grande Thor vier – então o nível de taints repele - todos os pods que tentam ser agendados em um nó que não atende aos - requisitos. + Por exemplo, os jobs do Thor devem estar todos no tipo + apropriado de VM. Se um trabalho grande do Thor aparecer, então o + nível de taints repele qualquer pod que tente ser agendado em um nó + que não atenda aos requisitos. - Para mais informações e exemplos de nossos Taints, Tolerations e - Placements, por favor, consulte nossa documentação de - desenvolvedor: + Para mais informações e exemplos de nossos Taints, Tolerâncias, + e Placements, por favor verifique nossa documentação de + desenvolvimento: https://github.com/hpcc-systems/HPCC-Platform/blob/master/helm/hpcc/docs/placements.md - Exemplos de Taints e Tolerations + Exemplos de Taints e tolerâncias - Os exemplos a seguir ilustram como algumas taints e - tolerations podem ser aplicadas. + Os exemplos a seguir ilustram como alguns taints e tolerâncias + podem ser aplicados. - O Kubernetes pode agendar um pod em qualquer pool de nós sem - uma taint. Nos exemplos a seguir, o Kubernetes só pode agendar os - dois componentes nas pools de nós com esses lables exatos, grupo e - gpu. + O Kubernetes pode agendar um pod para qualquer grupo de nós + sem um taint. Nos exemplos seguintes, o Kubernetes só pode agendar + os dois componentes para os grupos de nós com esses rótulos exatos, + group e gpu. placements: - pods: ["all"] @@ -1512,8 +1603,8 @@ value: "true" effect: "NoSchedule" - Várias tolerações também podem ser usadas. O exemplo a seguir - possui dois tolerations, grupo e GPU. + Também é possível usar múltiplas tolerations. O exemplo a + seguir possui duas tolerations, group e gpu. #The settings will be applied to all thor pods/jobs and myeclccserver pod and job - pods: ["thorworker-", "thor-thoragent", "thormanager-","thor-eclagent","hthor-"] @@ -1532,30 +1623,29 @@ Neste exemplo, o nodeSelector está impedindo o agendador do - Kubernetes de implementar qualquer/para todos nesta pool de nodes. - Sem taints, o agendador poderia implementar em qualquer pod na pool - de nodes. Utilizando o nodeSelector, a taint forçará o pod a ser - implementado apenas nos pods que correspondem a esse rótulo de node. - Existem duas restrições então, neste exemplo uma da pool de nós e a - outra do pod. + Kubernetes de implantar qualquer pod neste grupo de nós. Sem taints, + o agendador poderia implantar qualquer pod no grupo de nós. Ao + utilizar o nodeSelector, o taint forçará o pod a ser implantado + apenas nos nós que correspondem a esse rótulo de nó. Existem, então, + duas restrições neste exemplo: uma do grupo de nós e outra do + pod. - Restrições de Espalhamento de Topologia + Restrições de Dispersão Topológica - Você pode usar as restrições de distribuição de topologia para - controlar como os pods são distribuídos pelo seu cluster entre - domínios de falha, como regiões, zonas, nós e outros domínios de - topologia definidos pelo usuário. Isso pode ajudar a alcançar alta - disponibilidade, bem como a utilização eficiente dos recursos. Você - pode definir restrições ao nível do cluster como padrão, ou configurar - restrições de espalhamento de topologia para cargas de trabalho - individuais. As Restrições de Espalhamento de Topologia topologySpreadConstraints requer Kubernetes - v1.19+.ou maior. + Você pode usar restrições de dispersão topológica para controlar + como os pods são distribuídos em seu cluster entre domínios de falha, + como regiões, zonas, nós e outros domínios de topologia definidos pelo + usuário. Isso pode ajudar a alcançar alta disponibilidade e utilização + eficiente de recursos. Você pode definir restrições de dispersão + topológica ao nível do cluster como padrão, ou configurá-las para + cargas de trabalho individuais. As restrições de dispersão topológica + topologySpreadConstraints requerem + Kubernetes v1.19 ou superior. - Para mais informações veja: + Para mais informações: https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ @@ -1564,17 +1654,17 @@ https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ - Usando o exemplo de "topologySpreadConstraints", existem dois - agrupamentos de nós que têm "hpcc=nodepool1" e "hpcc=nodepool2" - respectivamente. Os pods Roxie serão agendados uniformemente nos dois - agrupamentos de nós. + Usando o exemplo de "topologySpreadConstraints", há dois grupos + de nós que têm "hpcc=nodepool1" e "hpcc=nodepool2", respectivamente. + Os pods do Roxie serão agendados de forma equitativa nos dois grupos + de nós. - Após a implementação, você pode verificar emitindo o seguinte + Após a implantação, você pode verificar emitindo o seguinte comando: kubectl get pod -o wide | grep roxie - O código substituto: + o código dos placements: - pods: ["type:roxie"] placement: @@ -1588,89 +1678,84 @@ - Afinidade (Affinity) e Anti-Afinidade (Anti-Affinity)` + Afinidade e Anti-Afinidade - A afinidade e a anti-afinidade expandem os tipos de restrições - que você pode definir. As regras de afinidade e anti-afinidade ainda - são baseadas nas labels. Além das labels, eles fornecem regras que - orientam o agendador do Kubernetes aonde colocar os pods com base em + A afinidade e anti-afinidade ampliam os tipos de restrições que + você pode definir. As regras de afinidade e anti-afinidade ainda são + baseadas nos rótulos. Além dos rótulos, elas fornecem regras que + orientam o agendador do Kubernetes sobre onde colocar pods com base em critérios específicos. A linguagem de afinidade/anti-afinidade é mais - expressiva do que labels simples e oferece mais controle sobre a + expressiva do que simples rótulos e oferece mais controle sobre a lógica de seleção. - Há dois tipos principais de afinidade. Afinidade de Nó (Node - Affinity) e Afinidade de Pod (Pod Affinity). + Existem dois tipos principais de afinidade: Afinidade de Nó + (Node Affinity) e Afinidade de Pod (Pod Affinity). - Node Affinity - - A afinidade de nós é semelhante ao conceito de seletor de nós, - que permite limitar em quais nós o seu pod pode ser agendado, com - base nas labels desses nós. Estes são usados para limitar os nós que - podem receber um pod, correspondendo às labels desses nós. A - afinidade de nós e a anti-afinidade de nós só podem ser usadas para - estabelecer afinidades positivas que atraem os pods para o nó. Isto - é realizado ao limitar os nós que podem receber um pod, - correspondendo às labels desses nós. A afinidade de nós e a - anti-afinidade de nós só podem ser usadas para estabelecer - afinidades positivas que atraem os pods para o nó. - - Não existe uma verificação de esquema para o conteúdo da - afinidade. Apenas uma afinidade pode ser aplicada a um pod ou job. - Se um pod/job corresponder a várias listas de pods de posição, então - apenas a última definição de afinidade será aplicada. Esta - solicitação foi feita com base no histórico de conversas - anteriores. - - Para mais informações, veja Afinidade de Nó + + A afinidade de nó (Node Affinity) é semelhante ao conceito de + nodeSelector, que permite restringir em quais nós seu pod pode ser + agendado com base nos rótulos dos nós. Ela é usada para restringir + os nós que podem receber um pod, combinando os rótulos desses nós. A + afinidade de nó e anti-afinidade só podem ser usadas para definir + afinidades positivas que atraem pods para o nó. + + Não há verificação de esquema para o conteúdo da afinidade. + Apenas uma afinidade pode ser aplicada a um pod ou job. Se um + pod/job corresponder a várias listas de posicionamento de pods, + então apenas a última definição de afinidade será aplicada. + + Para maiores informações, veja https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ - Existe dois tipos de afinidades de nó: + Existem dois tipos de afinidade de nós: requiredDuringSchedulingIgnoredDuringExecution: - O scheduler não consegue marcar o pod a menos que esta regra seja - cumprida. Esta função é semelhante ao nodeSelector, mas com uma + O agendador não pode agendar o pod a menos que esta regra seja + cumprida. Essa função é semelhante ao nodeSelector, mas com uma sintaxe mais expressiva. preferredDuringSchedulingIgnoredDuringExecution: - O scheduler tenta encontrar um nó que cumpra a regra. Se um nó - correspondente não estiver disponível, o scheduler ainda agenda o - pod. + O agendador tenta encontrar um nó que atenda à regra. Se um nó + correspondente não estiver disponível, o agendador ainda assim + agenda o pod. - Você pode especificar as afiidades do nós usando o campo - .spec.affinity.nodeAffinity na especificação no + Você pode especificar afinidades de nó usando o campo + spec.affinity.nodeAffinity na especificação do seu pod. - Pod Affinity - - O pod Affinity ou Inter-Pod Affinity é usada para limitar os - nós que podem receber um pod, de acordo com as labels dos pods já em - execução nesses nós. A afinidade de pod e a anti-afinidade de pod - podem ser tanto uma afinidade atraente quanto uma repulsa à - afinidade. - - A Inter-Pod Affinity funciona de maneira muito semelhante à - afinidade de nó, mas com algumas diferenças importantes. Os modos - "hard" e "soft" são indicados usando os mesmos campos - requiredDuringSchedulingIgnoredDuringExecution + Afinidade de Pod + + A afinidade de pod ou Inter-Pod Affinity é usada para + restringir os nós que podem receber um pod combinando os rótulos dos + pods existentes já em execução nesses nós. A afinidade de pod e + anti-afinidade pode ser tanto uma afinidade atrativa quanto uma + anti-afinidade repelente. + + A afinidade inter-pod funciona de maneira muito semelhante à + afinidade de nó, mas apresenta algumas diferenças importantes. Os + modos "hard" e "soft" são indicados usando os mesmos campos + requiredDuringSchedulingIgnoredDuringExecution e preferredDuringSchedulingIgnoredDuringExecution. - No entanto, estes deveriam estar aninhados sob os campos + No entanto, esses devem estar aninhados sob os campos spec.affinity.podAffinity ou - spec.affinity.podAntiAffinity dependendo de se - você deseja aumentar ou diminuir a afinidade do Pod. + preferredDuringSchedulingIgnoredDuringExecution, + dependendo se você deseja aumentar ou reduzir a afinidade do + pod. - Exemplo Affinity + Exemplo de Afinidade - O código a seguir ilustra o exemplo de affinity: + O código a seguir ilustra um exemplo de afinidade: - pods: ["thorworker-.*"] placement: - affinity: + affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: @@ -1681,10 +1766,10 @@ - e2e-az1 - e2e-az2 - Na seção 'schedulerName' a seguir, as configurações de - 'afinnity' também podem ser incluídas com este exemplo. + Na seção `schedulerName` a seguir, as configurações de + "afinidade" também podem ser incluídas com esse exemplo. - Nota: O valor "affinity" no + Nota: O valor "afinidade" no campo "schedulerName" é suportado apenas nas versões beta do Kubernetes 1.20.0 e posteriores. @@ -1695,14 +1780,14 @@ O campo schedulerName especifica o nome do agendador responsável por agendar um pod ou uma - job. No Kubernetes, você pode configurar vários agendadores com - diferentes nomes e perfis para rodar simultaneamente no + tarefa. No Kubernetes, você pode configurar vários agendadores com + nomes e perfis diferentes para serem executados simultaneamente no cluster. - Apenas um "schedulerName" pode ser aplicado a qualquer - pod/job. + Apenas um "schedulerName" pode ser aplicado a qualquer pod ou + job. - Um exemplo de schedulerName: + Exemplo de schedulerName: - pods: ["target:roxie"] placement: @@ -1722,82 +1807,76 @@ - - Básico sobre Helm e Yaml - - Esta seção destina-se a fornecer algumas informações básicas para - ajudá-lo a começar a implantação em contêineres do HPCC Systems. Existem - vários recursos disponíveis para aprender sobre arquivos Kubernetes, Helm - e YAML. Para obter mais informações sobre como usar essas ferramentas ou - para implantações em nuvem ou contêiner, consulte a respectiva - documentação. + + Fundamentos de Helm e YAML - In the previous section, we touched on the - values.yaml file and the - values-schema.json file. This section expands on some - of those concepts and how they might be applied when using the - containerized version of the HPCC Systems platform. + Esta seção destina-se a fornecer informações básicas para ajudá-lo a + iniciar sua implantação containerizada do HPCC Systems. Existem inúmeros + recursos disponíveis para aprender sobre Kubernetes, Helm e arquivos YAML. + Para mais informações sobre o uso dessas ferramentas, ou para implantações + em nuvem ou container, consulte a documentação respectiva. - Anteriormente, abordamos o arquivo values.yaml - e o arquivo values-schema.json. Esta seção expande alguns desses conceitos - e como eles podem ser aplicados ao usar a versão em contêiner da - plataforma HPCC Systems. + Na seção anterior, mencionamos os arquivos + values.yaml e + values-schema.json. Esta seção expande alguns desses + conceitos e como eles podem ser aplicados ao usar a versão containerizada + da plataforma HPCC Systems. - Estrutura do arquivo <emphasis>values.yaml</emphasis> + A estrutura de arquivos <emphasis>values.yaml</emphasis> - O arquivo values.yaml é um arquivo YAML que é - um formato frequentemente usado para arquivos de configuração. A - construção que compõe a maior parte de um arquivo YAML é o par - key-value, às vezes chamado de dicionário. A construção do par key-value - consiste em uma chave que aponta para alguns valores. Esses valores são - definidos pelo schema. + O arquivo values.yaml é um arquivo YAML, que + é um formato frequentemente usado para arquivos de configuração. A + estrutura que compõe a maior parte de um arquivo YAML é o par + chave-valor, às vezes referido como um dicionário. A construção de par + chave-valor consiste em uma chave que aponta para algum valor ou + valores. Esses valores são definidos pelo esquema. - Nesses arquivos de configuração, o recuo usado para representar o - relacionamento da estrutura do documento é muito importante. Os espaços - iniciais são significativos e as tabulações não são permitidas. + Nos arquivos de configuração, a indentação usada para representar + a estrutura do documento é bastante importante. Espaços à frente são + significativos e o uso de tabulações não é permitido. - Arquivos YAML são criados principalmente para dois tipos de - elementos: dictionários e listas. + Os arquivos YAML são compostos principalmente por dois tipos de + elementos: dicionários e listas. - Dicitionary + Dicionário - Dicionários são coleções de mapeamentos de valores-chave. Todas - as chaves diferenciam maiúsculas de minúsculas e, como mencionamos - anteriormente, o recuo também é crucial. Essas chaves devem ser - seguidas por dois pontos (:) e um espaço. Os dicionários também podem - ser aninhados. + Dicionários são coleções de mapeamentos chave-valor. Todas as + chaves são sensíveis a maiúsculas e minúsculas, e a indentação também + é crucial. Essas chaves devem ser seguidas por dois pontos (:) e um + espaço. - Por examplo: + Por exemplo: logging: detail: 80 - Isso é uma exemplo de dicionário para registro. + Este é um exemplo de um dicionário para logging. - Os dicionários nos arquivos de valores passados, como os do - arquivo myoverrides.yaml no exemplo abaixo, serão + Os dicionários nos arquivos de valores passados, como no arquivo + myoverrides.yaml no exemplo abaixo, serão mesclados nos dicionários correspondentes nos valores existentes, - começando com os valores padrão do chart helm entregue. + começando pelos valores padrão do gráfico do Helm do HPCC + entregue. helm install myhpcc hpcc/hpcc -f myoverrides.yaml Quaisquer valores pré-existentes em um dicionário que não sejam substituídos continuarão presentes no resultado mesclado. No entanto, - você pode sobrepor o conteúdo de um dicionário definindo-o como + você pode substituir o conteúdo de um dicionário definindo-o como nulo. Listas - Listas são grupos de elementos começando no mesmo nível de recuo - começando com um - (um hifen e um espaço). Cada elemento da lista é - recuado no mesmo nível e começa com um hífen e um espaço. As listas - também podem ser aninhadas e podem ser listas de dicionários, que por - sua vez também podem ter propriedades de uma lista. + Listas são grupos de elementos que começam no mesmo nível de + indentação, iniciando com um hífen e um espaço (-). Cada elemento da + lista é indentado no mesmo nível e começa com um hífen e um espaço. + Listas também podem ser aninhadas, e até mesmo ser listas de + dicionários. Um exemplo de uma lista de dicionários, com placement.tolerations como uma lista aninhada.: @@ -1809,34 +1888,32 @@ - key: "kubernetes.azure.com/scalesetpriority" - A entrada da lista aqui é indicada usando o hífen, que é um item - de entrada na lista, que é um dicionário com atributos aninhados. Em - seguida, o próximo hífen (no mesmo nível de indentação) é a próxima - entrada nessa lista. Uma lista pode ser uma lista de elementos de - valor simples ou os próprios elementos podem ser listas ou + A entrada da lista aqui é denotada usando o hífen, que é um item + de entrada na lista, que por sua vez é um dicionário com atributos + aninhados. Em seguida, o próximo hífen (no mesmo nível de indentação) + é a próxima entrada nessa lista. Uma lista pode ser uma lista de + elementos de valor simples, ou os elementos podem ser listas ou dicionários. - Seções do arquivo Values.yaml + Sessões do HPCC Systems Values.yaml - Primeira seção do arquivo values.yaml - descreve valores globais. Global normalmente se aplica a tudo. + A primeira seção do arquivo values.yaml + descreve valores globais. Global se aplica, em geral, a tudo. # Default values for hpcc. - global: # Settings in the global section apply to all HPCC components in all subcharts - -No trecho de arquivo values.yaml - fornecido pelo HPCC Systems, global:(acima), é o - dicionário de nível superior. Conforme observado nos comentários, as +No trecho do arquivo values.yaml do HPCC + Systems fornecido (acima), global: é o dicionário + de nível superior. Conforme observado nos comentários, as configurações na seção global se aplicam a todos os componentes do - HPCC Systems. Observe no nível de indentação que os outros valores + HPCC Systems. Note pelo nível de indentação que os outros valores estão aninhados nesse dicionário global. - Os itens definidos na seção global são compartilhados entre - todos os componentes. + Itens definidos na seção global são compartilhados entre todos + os componentes. Alguns exemplos de valores globais no arquivo values.yaml fornecido são as seções de armazenamento e segurança. @@ -1844,7 +1921,7 @@ global: storage: planes: - and also + e também security: eclSecurity: @@ -1855,67 +1932,63 @@ global: embedded: "allow" pipe: "allow" extern: "allow" - datafile: "allow"No exemplo acima, + datafile: "allow"Nos exemplos acima, storage: e security: são - valores globais. + valores globais do gráfico. - Uso do arquivo HPCC Systems Values.yaml + Utilização do HPCC Systems values.yaml O arquivo values.yaml do HPCC Systems é usado - pelo chart Helm para controlar como o HPCC Systems é implantado. O - arquivo de valores contém dicionários e listas, e eles podem ser - aninhados para criar estruturas mais complexas. O arquivo HPCC Systems - values.yaml destina-se a ser um guia de instalação - de demonstração de início rápido que não é apropriado para uso prático - não trivial. Você deve personalizar sua implantação para uma que seja - mais adequada às suas necessidades específicas. - - Mais informações sobre implantações personalizadas são abordadas - nas seções anteriores, bem como na documentação do Kubernetes e do - Helm. + pelo Helm chart para controlar como o HPCC Systems é implantado. O + values.yaml do HPCC Systems fornecido é destinado a + ser um guia de instalação do tipo quick start, que não é apropriado para + uso prático não trivial. Você deve personalizar sua implantação para + algo mais adequado às suas necessidades específicas. + + Informações adicionais sobre implantações personalizadas são + abordadas em seções anteriores, assim como na documentação do Kubernetes + e Helm. - Mesclando e Sobrescrevendo - - Tendo vários arquivos YAML, como um para registro, outro para - armazenamento, outro para secrects e assim por diante, permite uma - configuração granular. Esses arquivos de configuração podem estar - todos sob controle de versão. Podem ser versionados, verificados, etc. - e têm o benefício de apenas definir/alterar a área específica - necessária, garantindo que todas as áreas não alteradas sejam deixadas + Mesclagem e Sobreposição + + Ter vários arquivos YAML, como um para logging, outro para + armazenamento, e ainda outro para segredos, permite uma configuração + granular. Esses arquivos de configuração podem todos estar sob + controle de versão, onde podem ser versionados, verificados, etc. Isso + tem o benefício de definir/mudar apenas a área específica necessária, + enquanto garante que áreas não modificadas permaneçam intocadas. - A regra aqui é ter em mente onde vários arquivos YAML são - aplicados, os últimos sempre substituirão os valores dos anteriores. - Eles são sempre mesclados em sequência. Os valores são sempre - mesclados na ordem em que são fornecidos na linha de comando do - Helm. + A regra a ser lembrada aqui, ao aplicar vários arquivos YAML, é + que os últimos sempre sobrescreverão os valores nos primeiros. Eles + sempre são mesclados em sequência. Os valores são sempre mesclados na + ordem em que são fornecidos na linha de comando do Helm. - Outro ponto a considerar, onde existe um dicionário global como - root: e seu valor é redefinido no 2º arquivo (como um dicionário) ele - não seria sobrescrito. Você não pode simplesmente substituir um - dicionário. Você pode redefinir um dicionário e defini-lo como nulo - (como o exemplo Thor na seção anterior), o que efetivamente o - eliminará o primeiro. + Outro ponto a considerar é que, quando há um dicionário global + como root: e seu valor é redefinido em um segundo arquivo (como um + dicionário), ele não será sobrescrito. Você simplesmente não pode + sobrescrever um dicionário. Você pode redefinir um dicionário e + defini-lo como nulo, o que efetivamente apagará o primeiro. ATENÇÃO: Se você tivesse uma definição global (como storage.planes) e a mesclasse onde ela fosse - redefinida, eliminaria todas as definições da lista. + redefinida, isso apagaria todas as definições nessa lista. - Outro meio de eliminar todos os valores em uma lista é passar um - conjunto vazio denotado por um [ ], como este exemplo: + Another means to wipe out every value in a list is to pass in an + empty set denoted by a [ ] such as this example: - bundles: []Isso eliminaria - quaisquer propriedades definidas para pacotes configuráveis. + bundles: []Isso apagaria + quaisquer propriedades definidas para bundles. - Geralmente aplicável + Aplicações gerais - Esses itens são geralmente aplicáveis para nossos arquivos - YALM do HPCC Systems Helm. + Esses itens são geralmente aplicáveis aos nossos arquivos YAML + do HPCC Systems Helm. @@ -1927,68 +2000,140 @@ global: - Os serviços devem ser únicos. + Serviços devem ser únicos. - YAML são mesclados em sequência. + Arquivos YAML são mesclados em sequência. - Geralmente em relação aos componentes do HPCC Systems, os - componentes primeiramente são listas. Se você tiver uma lista de - valores vazia [ ], isso invalidaria essa lista em outro - lugar. + Em relação aos componentes do HPCC Systems, os componentes são + principalmente listas. Se você tiver uma lista de valores vazia + denotada por [ ], isso invalidaria essa lista em outros + lugares. - - - Additional Usage + + Utilização adicional - Os componentes do HPCC Systems são adicionados ou modificados - passando valores de substituição. Os valores do gráfico do Helm são - substituídos, seja passando o(s) arquivo(s) de valores de usando -f, - (para o arquivo de substituição) ou via --set onde você pode substituir - um único valor. Os valores passados são sempre mesclados na mesma ordem - em que são fornecidos na linha de comando do helm. + Os componentes do HPCC Systems são adicionados ou modificados + passando valores de substituição. Os valores do Helm chart são + substituídos, seja passando arquivos de substituição usando -f (para + arquivo de substituição) ou via --set, onde você pode substituir um + único valor. Esses valores passados são sempre mesclados na mesma + ordem em que são fornecidos na linha de comando do Helm. - Por exemplo, você pode + Por exemplo: - helm install myhpcc hpcc/hpcc -f myoverrides.yamlPara - sobrepor quaisquer valores entregues no values.yaml - passando por valores definidos em - myoverrides.yaml + helm install myhpcc hpcc/hpcc -f myoverrides.yamlSubstitui + quaisquer valores no values.yaml fornecido, + passando valores definidos em + myoverrides.yaml. - Você também pode utilizar --set conforme o exemplo a - seguir: + Você também pode usar --set conforme o seguinte exemplo: - helm install myhpcc hpcc/hpcc --set storage.daliStorage.plane=dali-plane + helm install myhpcc hpcc/hpcc --set storage.daliStorage.plane=dali-plane - Para sobrepor somente um arquivo em específico. + Para sobrepor somente um valor em específico. - É até possível combinar substituições de arquivo e valor único, - por exemplo: + É até possível combinar substituições de arquivo e de valor + único, por exemplo: - Para substituir apenas o valor global.image.version. Novamente, a - ordem em que os valores são mesclados é a mesma em que são emitidos na - linha de comando. Agora considere: + helm install myhpcc hpcc/hpcc -f myoverrides.yaml --set storage.daliStorage.plane=dali-plane - helm install myhpcc hpcc/hpcc -f myoverrides.yaml --set storage.daliStorage.plane=dali-plane + No exemplo anterior, a flag --set substitui o valor para + storage.daliStorage.plane (se) definido no + myoverrides.yaml, que substituiria qualquer + configuração do arquivo values.yaml e resultaria + na definição de seu valor para dali-plane. - No exemplo anterior, a flag --set substitui o valor para - storage.daliStorage.plane (if) definido no - myoverrides.yaml, que substituiria qualquer - configuração do arquivo values.yaml e resultaria na - configuração de seu valor como dali-plane. + Se a flag --set for usada no comando helm + install ou helm upgrade, esses valores são simplesmente convertidos + para YAML no lado do cliente. - Se a flag --set for usada na instalação do - helm ou na atualização do helm, esses valores serão simplesmente - convertidos em YAML no lado do cliente. + Você pode especificar as flags de substituição várias vezes. A + prioridade será dada ao último (mais à direita) arquivo + especificado. + + + + Configurações Global/Expert + + A seção 'expert' em 'global' do values.yaml deve ser usada para + definir configurações de baixo nível, de teste ou de desenvolvedor. + Esta seção do helm chart é destinada a ser usada para opções + personalizadas, de baixo nível ou de depuração, portanto, na maioria + das implantações, deve permanecer vazia. + + Este é um exemplo de como a seção global/avançada pode se + parecer: + + global: + expert: + numRenameRetries: 3 + maxConnections: 10 + keepalive: + time: 200 + interval: 75 + probes: 9 + - Você pode especificar as flags de substituição várias vezes. A - prioridade será dada ao último arquivo (mais à direita) - especificado. + NOTA: Alguns componentes (como o DfuServer e Thor) também + possuem uma área de configurações 'avançadas' (veja o esquema de + valores) que pode ser usada para configurações relevantes em uma base + por instância de componente, em vez de defini-las globalmente. + + As seguintes opções estão disponíveis: + + + + numRenameRetries + + + (unsigned) Se definido para um número positivo, a + plataforma tentará novamente renomear um arquivo físico em + caso de falha (após um curto atraso). Normalmente, isso não + deveria ser necessário, mas em alguns sistemas de arquivos + pode ajudar a mitigar problemas onde o arquivo acabou de ser + fechado e não foi exposto corretamente na camada posix. + + + + + maxConnections + + + (unsigned) Esta é uma configuração do Servidor DFU. Se + definido, irá limitar o número máximo de conexões paralelas e + streams de partição que estarão ativas ao mesmo tempo. Por + padrão, um trabalho DFU executará tantas conexões/streams + ativas quanto houver partições envolvidas no spray, limitado a + um máximo absoluto de 800. A configuração maxConnections pode + ser usada para reduzir essa concorrência. Isso pode ser útil + em alguns cenários onde a concorrência está causando + congestionamento na rede e desempenho degradado. + + + + + keepalive + + + (time: sem sinal, interval: sem sinal, probes: sem + sinal) Veja o exemplo de keepalive acima. Se definido, essas + configurações irão substituir as configurações padrão de + keepalive do soquete do sistema cada vez que a plataforma + criar um soquete. Isso pode ser útil em alguns cenários se as + conexões forem fechadas prematuramente por fatores externos + (por exemplo, firewalls). Um exemplo disso é que instâncias do + Azure irão fechar soquetes que permaneceram ociosos por mais + de 4 minutos quando conectados fora de suas redes. + + + + - \ No newline at end of file + diff --git a/esp/src/src-react/components/Logs.tsx b/esp/src/src-react/components/Logs.tsx index a1fad7bab0d..5e697c77b55 100644 --- a/esp/src/src-react/components/Logs.tsx +++ b/esp/src/src-react/components/Logs.tsx @@ -3,7 +3,7 @@ import { CommandBar, ContextualMenuItemType, ICommandBarItemProps } from "@fluen import { GetLogsExRequest, LogaccessService, LogType, TargetAudience, WsLogaccess } from "@hpcc-js/comms"; import { Level, scopedLogger } from "@hpcc-js/util"; import nlsHPCC from "src/nlsHPCC"; -import { logColor, removeAllExcept, wuidToDate, wuidToTime } from "src/Utility"; +import { formatDateString, logColor, removeAllExcept, timestampToDate, wuidToDate, wuidToTime } from "src/Utility"; import { useLogAccessInfo } from "../hooks/platform"; import { HolyGrail } from "../layouts/HolyGrail"; import { pushParams } from "../util/history"; @@ -133,7 +133,17 @@ export const Logs: React.FunctionComponent = ({ } }); const retVal = { - timestamp: { label: nlsHPCC.TimeStamp, width: 140, sortable: false, }, + timestamp: { + label: nlsHPCC.TimeStamp, width: 140, sortable: false, + formatter: ts => { + if (ts) { + if (ts.indexOf(":") < 0) { + return timestampToDate(ts).toISOString(); + } + return formatDateString(ts); + } + }, + }, message: { label: nlsHPCC.Message, width: 600, sortable: false, }, components: { label: nlsHPCC.ContainerName, width: 150, sortable: false }, instance: { label: nlsHPCC.PodName, width: 150, sortable: false }, diff --git a/esp/src/src/Utility.ts b/esp/src/src/Utility.ts index 2d6686a4a40..d17b93257cb 100644 --- a/esp/src/src/Utility.ts +++ b/esp/src/src/Utility.ts @@ -1257,6 +1257,14 @@ export function timestampToDate(timestamp: number): Date { return new Date(millis); } +export function formatDateString(dateStr: string): string { + const matches = dateStr.match(/([0-9]{4}(?:-[0-9]{1,2})+)([T\s])((?:[0-9]{1,2}:)+[0-9]{1,2}\.[0-9]{1,3})(Z*)/); + if (matches) { + return `${matches[1]}T${matches[3]}${matches[4] ? matches[4] : "Z"}`; + } + return dateStr; +} + const theme = getTheme(); const { semanticColors } = theme;