Uma iRule é um conjunto de handlers de eventos. Você escreve blocos como when HTTP_REQUEST { ... }, e o BIG-IP executa cada bloco quando o evento dele dispara. Os eventos não são arbitrários — eles disparam em uma sequência específica que espelha como uma conexão é de fato processada, e quais eventos aparecem depende de quais perfis estão anexados ao virtual server.
O caminho feliz, de ponta a ponta
Para um virtual server HTTPS completo que recriptografa para o pool (um perfil Client-SSL, um perfil HTTP, um perfil Server-SSL e um pool), os eventos comuns disparam nesta ordem:
CLIENT_ACCEPTED conexão TCP do cliente estabelecida
CLIENTSSL_CLIENTHELLO ClientHello TLS do cliente recebido
CLIENTSSL_HANDSHAKE handshake TLS do lado cliente concluído
HTTP_REQUEST cabeçalhos completos da requisição analisados
LB_SELECTED membro do pool escolhido
SERVER_CONNECTED conexão ao membro estabelecida
SERVERSSL_HANDSHAKE handshake TLS do lado servidor concluído
HTTP_REQUEST_SEND prestes a enviar a requisição ao servidor
HTTP_RESPONSE status e cabeçalhos da resposta analisados
SERVER_CLOSED conexão do lado servidor encerrada
CLIENT_CLOSED conexão do lado cliente encerrada
Remova um perfil e os eventos relacionados simplesmente somem. Tire o perfil HTTP e você fica com um fluxo TCP puro: CLIENT_ACCEPTED, LB_SELECTED, SERVER_CONNECTED, SERVER_CLOSED, CLIENT_CLOSED. Tire o pool e não há para onde balancear, então LB_SELECTED e todos os eventos do lado servidor desaparecem.
Por que a ordem importa
A ordem não é trivialidade — ela dita quais dados estão disponíveis e quando. HTTP::header funciona em HTTP_REQUEST porque os cabeçalhos já foram analisados àquela altura; chamá-lo em CLIENT_ACCEPTED dá erro, porque nesse ponto o BIG-IP tem uma conexão TCP e nada mais. Comandos de seleção de pool pertencem antes de LB_SELECTED; comandos de resposta só fazem sentido de HTTP_RESPONSE em diante. Boa parte dos erros de execução de iRule é, na verdade, um erro de ordem de evento — tocar em algo que ainda não existe.
Um mapa, não o território
Explicador da ordem de eventos de iRules modela a ordem documentada para um virtual server Standard (full-proxy), que cobre a grande maioria dos casos de uso de BIG-IP LTM - Local Traffic Manager. O conjunto exato também depende de módulos: BIG-IP Zero Trust Access (antigo BIG-IP APM - Access Policy Manager), F5 AWAF - Advanced (antigo BIG-IP ASM - Application Security Manager) e outros adicionam seus próprios eventos. Também depende de a sua iRule coletar dados explicitamente. Use-a para raciocinar sobre onde no fluxo a sua lógica deve viver, e depois confirme contra uma configuração real para qualquer coisa incomum.
Esta série, em ordem
Este artigo abre a série Eventos de iRules e o ciclo de vida da conexão. Ele percorre os eventos na ordem em que uma conexão os dispara; as partes respondem às perguntas que essa ordem levanta: qual lado do proxy um evento enxerga, por que um evento pode não existir num virtual server, o que o handshake acrescenta, qual de várias regras roda primeiro, e como escolher o evento antes de escolher os comandos.
- Lado cliente vs lado servidor em iRules. Um proxy completo mantém duas conexões, e o mesmo comando devolve coisas diferentes em cada lado.
- O que faz um evento disparar: provisionamento e perfis. Um evento só existe quando o seu módulo está provisionado e o seu perfil está anexado, e alguns precisam de um terceiro ingrediente.
- FastL4 vs Standard: quais eventos de iRule você tem. Os eventos ricos do proxy TCP completo contra o caminho rápido que abre mão da maioria deles de propósito.
- Eventos de handshake SSL em iRules. Os eventos em volta do handshake TLS, e o evento do ClientHello que torna possível a seleção por .
- Prioridade de iRule e múltiplas regras. Quando várias iRules escutam o mesmo evento, a prioridade decide qual roda primeiro.
- Como escrever uma iRule: a ordem em que as perguntas vêm. Evento primeiro, comandos em segundo, custo em terceiro: por que o desempenho é a última pergunta e não a primeira.