# IronPDF on Azure Linux with WEBSITE_RUN_FROM_PACKAGE
Ao implantar uma API .NET usando IronPDF em um Azure Linux App Service com `WEBSITE_RUN_FROM_PACKAGE` habilitado, o renderizador do Chrome não é implantado e o aplicativo lança um erro na inicialização.
```txt
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
```
Quando `WEBSITE_RUN_FROM_PACKAGE` está configurado, o diretório `/home/site/wwwroot` torna-se somente leitura. O IronPDF precisa extrair os binários do renderizador nativo do Chrome e as bibliotecas de runtime para um local gravável na inicialização, então a restrição de somente leitura bloqueia a implantação. Além disso, o ambiente Linux padrão do Azure pode não ter as bibliotecas do sistema necessárias pré-instaladas, o que causa erros de objeto compartilhado ausente.
## Solução
Três opções estão disponíveis dependendo das suas restrições de implantação.
### Opção 1: Instalar Dependências Faltantes via SSH
Acesse o App Service via SSH e execute os seguintes comandos para instalar as bibliotecas do sistema necessárias:
```bash
apt update
apt install -y libc6-dev libgtk2.0-0 libnss3 libatk-bridge2.0-0 \
libx11-xcb1 libxcb-dri3-0 libdrm-common libgbm1 libasound2 \
libxkbcommon-x11-0 libxrender1 libfontconfig1 libxshmfence1
```
Esta é uma solução temporária. Pacotes instalados desta forma não persistem em reinicializações e não são adequados para ambientes de produção que possuem restrições de firewall de saída. Para a lista completa de pacotes necessários por distribuição Linux, veja o [guia de implantação Linux](/get-started/linux/).
### Opção 2: Use um Container Docker Personalizado (Recomendado para Linux)
Construa uma imagem Docker personalizada baseada em Ubuntu ou Debian, instale os pacotes do sistema necessários com `apt`, e inclua os pacotes NuGet `IronPdf` e `IronPdf.Native.Chrome.Linux` no seu arquivo de projeto. Esta abordagem oferece ao renderizador um sistema de arquivos gravável e dependências pré-instaladas no momento da compilação da imagem.
Adicione os pacotes NuGet correspondentes ao seu `.csproj`:
```xml
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
```
Certifique-se de que a versão de `IronPdf.Native.Chrome.Linux` coincide com a versão do pacote `IronPdf`. Incluir o pacote nativo no projeto impede que IronPDF tente um download em tempo de execução, o qual falharia em um ambiente de somente leitura ou com restrição de rede.
Veja o [guia Docker do IronPDF](/get-started/ironpdf-docker/) para um exemplo completo de Dockerfile.
### Opção 3: Migrar para um Windows App Service
Windows App Services não têm as mesmas restrições de permissão de sistema de arquivos para `WEBSITE_RUN_FROM_PACKAGE`. As bibliotecas de runtime do IronPDF para Windows são suportadas nativamente e podem ser extraídas sem problemas. Migrar para um Windows App Service remove completamente a causa raiz.
Ao implantar uma API .NET usando IronPDF em um Azure Linux App Service com WEBSITE_RUN_FROM_PACKAGE habilitado, o renderizador do Chrome não é implantado e o aplicativo lança um erro na inicialização.
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
Text
Quando WEBSITE_RUN_FROM_PACKAGE está configurado, o diretório /home/site/wwwroot torna-se somente leitura. O IronPDF precisa extrair os binários do renderizador nativo do Chrome e as bibliotecas de runtime para um local gravável na inicialização, então a restrição de somente leitura bloqueia a implantação. Além disso, o ambiente Linux padrão do Azure pode não ter as bibliotecas do sistema necessárias pré-instaladas, o que causa erros de objeto compartilhado ausente.
Solução
Três opções estão disponíveis dependendo das suas restrições de implantação.
Opção 1: Instalar Dependências Faltantes via SSH
Acesse o App Service via SSH e execute os seguintes comandos para instalar as bibliotecas do sistema necessárias:
Esta é uma solução temporária. Pacotes instalados desta forma não persistem em reinicializações e não são adequados para ambientes de produção que possuem restrições de firewall de saída. Para a lista completa de pacotes necessários por distribuição Linux, veja o guia de implantação Linux.
Opção 2: Use um Container Docker Personalizado (Recomendado para Linux)
Construa uma imagem Docker personalizada baseada em Ubuntu ou Debian, instale os pacotes do sistema necessários com apt, e inclua os pacotes NuGet IronPdf e IronPdf.Native.Chrome.Linux no seu arquivo de projeto. Esta abordagem oferece ao renderizador um sistema de arquivos gravável e dependências pré-instaladas no momento da compilação da imagem.
Adicione os pacotes NuGet correspondentes ao seu .csproj:
Certifique-se de que a versão de IronPdf.Native.Chrome.Linux coincide com a versão do pacote IronPdf. Incluir o pacote nativo no projeto impede que IronPDF tente um download em tempo de execução, o qual falharia em um ambiente de somente leitura ou com restrição de rede.
Windows App Services não têm as mesmas restrições de permissão de sistema de arquivos para WEBSITE_RUN_FROM_PACKAGE. As bibliotecas de runtime do IronPDF para Windows são suportadas nativamente e podem ser extraídas sem problemas. Migrar para um Windows App Service remove completamente a causa raiz.
Curtis Chau é bacharel em Ciência da Computação (Universidade Carleton) e se especializa em desenvolvimento front-end, com experiência em Node.js, TypeScript, JavaScript e React. Apaixonado por criar interfaces de usuário intuitivas e esteticamente agradáveis, Curtis gosta de trabalhar com frameworks modernos e criar manuais bem estruturados e visualmente atraentes.
