aiac
v5.3.0
Infrastructure d'intelligence artificielle Générateur en tant que code.
aiac est un outil de bibliothèque et de ligne de commande pour générer des modèles IAC (infrastructure en code), configurations, utilitaires, requêtes et plus via des fournisseurs LLM tels que OpenAI, Amazon Bedrock et Olllama.
La CLI vous permet de demander à un modèle de générer des modèles pour différents scénarios (par exemple "Get Terraform pour AWS EC2"). Il compose une demande appropriée au fournisseur sélectionné et stocke le code résultant à un fichier et / ou l'imprime à la sortie standard.
Les utilisateurs peuvent définir plusieurs "backends" ciblant différents fournisseurs et environnements LLM à l'aide d'un fichier de configuration simple.
aiac terraform for a highly available eksaiac pulumi golang for an s3 with sns notificationaiac cloudformation for a neptundbaiac dockerfile for a secured nginxaiac k8s manifest for a mongodb deploymentaiac jenkins pipeline for building nodejsaiac github action that plans and applies terraform and sends a slack notificationaiac opa policy that enforces readiness probe at k8s deploymentsaiac python code that scans all open ports in my networkaiac bash script that kills all active terminal sessionsaiac kubectl that gets ExternalIPs of all nodesaiac awscli that lists instances with public IP address and Nameaiac mongo query that aggregates all documents by created dateaiac elastic query that applies a condition on a value greater than some value in aggregationaiac sql query that counts the appearances of each row in one table in another table based on an id column Avant d'installer / exécuter aiac , vous devrez peut-être configurer vos fournisseurs LLM ou collecter des informations.
Pour OpenAI , vous aurez besoin d'une clé API pour que aiac fonctionne. Reportez-vous au modèle de tarification d'Openai pour plus d'informations. Si vous n'utilisez pas l'API hébergée par OpenAI (par exemple, vous pouvez utiliser Azure OpenAI), vous devrez également fournir le point de terminaison de l'URL de l'API.
Pour le substratum rocheux d'Amazon , vous aurez besoin d'un compte AWS avec le substratum rocheux et de l'accès aux modèles pertinents. Reportez-vous à la documentation du fondement pour plus d'informations.
Pour Ollama , vous n'avez besoin que de l'URL vers le serveur API Olllama local, y compris le préfixe de chemin / API. Cela par défaut est http: // localhost: 11434 / api. Olllama ne fournit pas de mécanisme d'authentification, mais on peut être en place en cas de serveur proxy utilisé. Ce scénario n'est pas actuellement soutenu par aiac .
Via brew :
brew tap gofireflyio/aiac https://github.com/gofireflyio/aiac
brew install aiac
Utilisation de docker :
docker pull ghcr.io/gofireflyio/aiac
Utilisation go install :
go install github.com/gofireflyio/aiac/v5@latest
Alternativement, cloner le référentiel et construire à partir de la source:
git clone https://github.com/gofireflyio/aiac.git
go build
aiac est également disponible dans le référentiel utilisateur Arch Linux (AUR) en tant qu'AIAC (qui compile à partir de Source) et AIAC-BIN (qui télécharge un exécutable compilé).
aiac est configuré via un fichier de configuration Toml. À moins qu'un chemin spécifique ne soit fourni, aiac recherche un fichier de configuration dans le répertoire XDG_CONFIG_HOME de l'utilisateur, en particulier ${XDG_CONFIG_HOME}/aiac/aiac.toml . Sur les systèmes d'exploitation de type UNIX, cela sera par défaut "~ / .config / aacak / AIAC.Toml". Si vous souhaitez utiliser un chemin différent, fournissez l'indicateur --config ou -c avec le chemin du fichier.
Le fichier de configuration définit un ou plusieurs backends nommés. Chaque backend a un type identifiant le fournisseur LLM (par exemple "Openai", "Bedrock", "Olllama") et divers paramètres pertinents pour ce fournisseur. Plusieurs backends du même fournisseur LLM peuvent être configurés, par exemple pour des environnements "mise en scène" et "production".
Voici un exemple de fichier de configuration:
default_backend = " official_openai " # Default backend when one is not selected
[ backends . official_openai ]
type = " openai "
api_key = " API KEY "
# Or
# api_key = "$OPENAI_API_KEY"
default_model = " gpt-4o " # Default model to use for this backend
[ backends . azure_openai ]
type = " openai "
url = " https://tenant.openai.azure.com/openai/deployments/test "
api_key = " API KEY "
api_version = " 2023-05-15 " # Optional
auth_header = " api-key " # Default is "Authorization"
extra_headers = { X-Header-1 = " one " , X-Header-2 = " two " }
[ backends . aws_staging ]
type = " bedrock "
aws_profile = " staging "
aws_region = " eu-west-2 "
[ backends . aws_prod ]
type = " bedrock "
aws_profile = " production "
aws_region = " us-east-1 "
default_model = " amazon.titan-text-express-v1 "
[ backends . localhost ]
type = " ollama "
url = " http://localhost:11434/api " # This is the defaultNotes:
default_model ). S'il n'est pas fourni, les appels qui ne définissent pas un modèle échoueront.auth_header . Cela par défaut «l'autorisation», mais Azure OpenAI utilise «API-Key» à la place. Lorsque l'en-tête est soit «autorisation» ou «autauthorisation proxy», la valeur de l'en-tête pour les demandes sera «porteur API_KEY». Si c'est autre chose, ce sera simplement "api_key".extra_headers . Une fois un fichier de configuration créé, vous pouvez commencer à générer du code et vous n'avez qu'à vous référer au nom du backend. Vous pouvez utiliser aiac à partir de la ligne de commande ou comme bibliothèque Go.
Avant de commencer à générer du code, vous pouvez répertorier tous les modèles disponibles dans un backend:
aiac -b aws_prod --list-models
Cela renverra une liste de tous les modèles disponibles. Notez que selon le fournisseur LLM, cela peut énumérer des modèles qui ne sont pas accessibles ou activés pour le compte spécifique.
Par défaut, AIAC imprime le code extrait en sortie standard et ouvre un shell interactif qui permet de converser avec le modèle, de réessayer les demandes, d'enregistrer la sortie en fichiers, de copier le code dans le presse-papiers, etc.:
aiac terraform for AWS EC2
Cela utilisera le backend par défaut dans le fichier de configuration et le modèle par défaut pour ce backend, en supposant qu'ils sont effectivement définis. Pour utiliser un backend spécifique, fournissez le --backend ou -b Flag:
aiac -b aws_prod terraform for AWS EC2
Pour utiliser un modèle spécifique, fournissez l'indicateur --model ou -m :
aiac -m gpt-4-turbo terraform for AWS EC2
Vous pouvez demander à aiac de sauvegarder le code résultant dans un fichier spécifique:
aiac terraform for eks --output-file=eks.tf
Vous pouvez également utiliser un drapeau pour enregistrer la sortie complète de Markdown:
aiac terraform for eks --output-file=eks.tf --readme-file=eks.md
Si vous préférez AIAC à imprimer la sortie de marque complète à la sortie standard plutôt qu'au code extrait, utilisez l'indicateur -f ou --full :
aiac terraform for eks -f
Vous pouvez utiliser AIAC en mode non interactif, en imprimant simplement le code généré en sortie standard et en le enregistrant éventuellement dans des fichiers avec les drapeaux ci-dessus, en fournissant le drapeau -q ou --quiet :
aiac terraform for eks -q
En mode calme, vous pouvez également envoyer le code résultant dans le presse-papiers en fournissant l'indicateur --clipboard :
aiac terraform for eks -q --clipboard
Notez que l'AIAC ne quittera pas dans ce cas tant que le contenu du presse-papiers ne changera pas. Cela est dû à la mécanique du presse-papiers.
Toutes les mêmes instructions s'appliquent, sauf que vous exécutez une image docker :
docker run
-it
-v ~/.config/aiac/aiac.toml:~/.config/aiac/aiac.toml
ghcr.io/gofireflyio/aiac terraform for ec2
Vous pouvez utiliser aiac comme bibliothèque Go:
package main
import (
"context"
"log"
"os"
"github.com/gofireflyio/aiac/v5/libaiac"
)
func main () {
aiac , err := libaiac . New () // Will load default configuration path.
// You can also do libaiac.New("/path/to/aiac.toml")
if err != nil {
log . Fatalf ( "Failed creating aiac object: %s" , err )
}
ctx := context . TODO ()
models , err := aiac . ListModels ( ctx , "backend name" )
if err != nil {
log . Fatalf ( "Failed listing models: %s" , err )
}
chat , err := aiac . Chat ( ctx , "backend name" , "model name" )
if err != nil {
log . Fatalf ( "Failed starting chat: %s" , err )
}
res , err = chat . Send ( ctx , "generate terraform for eks" )
res , err = chat . Send ( ctx , "region must be eu-central-1" )
} La version 5.0.0 a introduit un changement significatif de l'API aiac dans les formulaires de ligne de commande et de bibliothèque, conformément aux commentaires de la communauté.
Avant V5, il n'y avait pas de concept de fichier de configuration ou de backends nommés. Les utilisateurs devaient fournir toutes les informations nécessaires pour contacter un fournisseur LLM spécifique via des indicateurs de ligne de commande ou des variables d'environnement, et la bibliothèque a permis de créer un objet "client" qui ne pouvait parler qu'avec un seul fournisseur LLM.
Les backends sont désormais configurés uniquement via le fichier de configuration. Reportez-vous à la section de configuration pour les instructions. Des drapeaux spécifiques aux fournisseurs tels que --api-key , --aws-profile , etc. (et leurs variables d'environnement respectives, le cas échéant) ne sont plus acceptées.
Depuis V5, les backends sont également nommés. Auparavant, les indicateurs --backend et -b faisaient référence au nom du fournisseur LLM (par exemple "Openai", "Bedrock", "Olllama"). Maintenant, ils se réfèrent au nom que vous avez défini dans le fichier de configuration:
[ backends . my_local_llm ]
type = " ollama "
url = " http://localhost:11434/api " Ici, nous configurons un backend Olllama nommé "MY_LOCAL_LLM". Lorsque vous souhaitez générer du code avec ce backend, vous utiliserez -b my_local_llm plutôt que -b ollama , car plusieurs backends peuvent exister pour le même fournisseur LLM.
Avant V5, la ligne de commande a été divisée en trois sous-communs: get , list-models et version . En raison de cette nature hiérarchique de la CLI, les drapeaux n'ont peut-être pas été acceptés s'ils étaient fournis dans le "mauvais emplacement". Par exemple, le drapeau --model a dû être fourni après le mot «obtenir», sinon il ne serait pas accepté. Dans V5, il n'y a pas de sous-commandes, donc la position des drapeaux n'a plus d'importance.
La sous-commande list-models est remplacée par les --list-models de drapeaux et la sous-commande version est remplacée par l' --version de drapeau.
Avant V5:
aiac -b ollama list-models
Depuis V5:
aiac -b my_local_llm --list-models
Dans les versions antérieures, le mot "Get" était en fait une sous-commande et ne faisait pas vraiment partie de l'invite envoyée au fournisseur LLM. Depuis V5, il n'y a pas de sous-commande "Get", vous n'avez donc plus besoin d'ajouter ce mot à vos invites.
Avant V5:
aiac get terraform for S3 bucket
Depuis V5:
aiac terraform for S3 bucket
Cela dit, l'ajout du mot «obtenir» ou «générer» ne fera pas de mal, car la V5 le supprimera simplement si elle est fournie.
Avant V5, les modèles pour chaque fournisseur LLM ont été codés en dur dans chaque implémentation backend, et chaque fournisseur avait un modèle par défaut codé en dur. Cela a considérablement limité la convivialité du projet et nous a obligés à mettre à jour aiac chaque fois que de nouveaux modèles étaient ajoutés ou obsolètes. D'un autre côté, nous pourrions fournir des informations supplémentaires sur chaque modèle, telles que ses longueurs de contexte et son type, car nous les avons extrait manuellement de la documentation du fournisseur.
Depuis V5, aiac ne code plus en hard les modèles, y compris ceux par défaut. Il n'essaiera pas de vérifier le modèle que vous sélectionnez existe réellement. L'indicateur --list-models contactera désormais directement l'API Backend choisi pour obtenir une liste de modèles pris en charge. La définition d'un modèle lors de la génération de code envoie simplement son nom à l'API tel quel. De plus, au lieu de coder en dur un modèle par défaut pour chaque backend, les utilisateurs peuvent définir leurs propres modèles par défaut dans le fichier de configuration:
[ backends . my_local_llm ]
type = " ollama "
url = " http://localhost:11434/api "
default_model = " mistral:latest " Avant V5, aiac a pris en charge les modèles d'achèvement et les modèles de chat. Depuis V5, il ne prend en charge que les modèles de chat. Étant donné qu'aucune des API du fournisseur LLM ne note réellement si un modèle est un modèle d'achèvement ou un modèle de discussion (ou même un modèle d'image ou de vidéo), l'indicateur de --list-models peut énumérer des modèles qui ne sont pas réellement utilisables et tenter d'utiliser eux entraîneront une erreur renvoyée de l'API du fournisseur. La raison pour laquelle nous avons décidé de supprimer le support pour les modèles d'achèvement était qu'ils nécessitent de définir une quantité maximale de jetons pour que l'API génére (au moins dans OpenAI), ce que nous ne pouvons plus faire sans connaître la longueur du contexte. Les modèles de chat sont non seulement beaucoup plus utiles, mais ils n'ont pas cette limitation.
La plupart des API du fournisseur LLM, lors du retour d'une réponse à une invite, comprendront une "raison" pour savoir pourquoi la réponse s'est terminée là où elle l'a fait. Généralement, la réponse doit se terminer parce que le modèle a terminé la génération d'une réponse, mais parfois la réponse peut être tronquée en raison de la longueur de contexte du modèle ou de l'utilisation du jeton de l'utilisateur. Lorsque la réponse ne s'est pas "arrêtée" car elle a terminé la génération, la réponse serait "tronquée". Avant V5, si l'API retournait que la réponse a été tronquée, aiac a renvoyé une erreur. Depuis V5, une erreur n'est plus renvoyée, car il semble que certains fournisseurs ne renvoient pas une raison d'arrêt précise. Au lieu de cela, la bibliothèque renvoie la raison d'arrêter dans le cadre de sa sortie pour que les utilisateurs décident comment procéder.
Invite de ligne de commande:
aiac dockerfile for nodejs with comments
Sortir:
FROM node:latest
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./
RUN npm install
# If you are building your code for production
# RUN npm ci --only=production
# Bundle app source
COPY . .
EXPOSE 8080
CMD [ "node" , "index.js" ]La plupart des erreurs que vous êtes susceptibles de rencontrer proviennent de l'API du fournisseur LLM, par exemple OpenAI ou Amazon Bedrock. Certaines erreurs courantes que vous pouvez rencontrer sont:
"[insuffisant_quota] Vous avez dépassé votre quota actuel, veuillez vérifier votre plan et vos détails de facturation": Comme décrit dans la section Instructions, OpenAI est une API payante avec un certain montant de crédits gratuits. Cette erreur signifie que vous avez dépassé votre quota, que ce soit gratuit ou payant. Vous devrez recharger pour poursuivre l'utilisation.
"La limite de taux [des jetons] atteint ...": L'API OpenAI utilise la limitation des taux comme décrit ici. aiac effectue uniquement des demandes individuelles et ne peut pas de contournement ou empêcher ces limites de taux. Si vous utilisez aiac en programme, vous devrez implémenter vous-même. Voir ici pour des conseils.
Ce code est publié selon les termes de l'Apache License 2.0.
