search

FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
89 stars 12 forks source link

Kickstart example for initial setup #446

Open trollr opened 4 years ago

trollr commented 4 years ago

Kickstart example for initial setup

Description

Provide an example to show how to kickstart fusionauth initial setup. Think this is the most valuable case

soullivaneuh commented 4 years ago

Would be great, and BTW, I really don't see the point of this feature currently.

Basically, it's API requests list on a json file. I did the same before on a bash script.

What is the point of this? Why not provide a real configuration structure in yaml or even json?

soullivaneuh commented 4 years ago

Also:

Kickstart will only run if no API keys, users or tenants exist, so you can safely leave this environment variable configured even after the system has been configured.

Is at applicable for any or your request? In this case it might be wrong like for #430 and #436.

Indeed, files like templates and translations may be versioned and edited before deploy. If the kick-start run only once, the template would never be updated. Am I right? But Maybe it's an another subject.

robotdan commented 4 years ago

@trollr @soullivaneuh did you review the Kickstart doc here, if so did you still have questions about how to use the feature? https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

If you're looking for a full example kickstart file, I can post the one we use in development.

Basically, it's API requests list on a json file. I did the same before on a bash script.

This is partially correct. The problem before was you had to manually perform an INSERT to get an API key configured and then wait for the cache to load in order to make API requests. The basic case outlined in the Kickstart above is just to insert an API key and then you can make all of the requests you like using your bash script.

The advanced features allow you to read in values via environment variable, change the default tenant Id if you want to hard code it in your application, etc.

Indeed, files like templates and translations may be versioned and edited before deploy. If the kick-start run only once, the template would never be updated. Am I right? But Maybe it's an another subject.

If I understand the question, yes it runs only at initial start to get FusionAuth setup for production or development purposes.

Re: https://github.com/FusionAuth/fusionauth-issues/issues/430 - if you want to get the theme set up how you like initially this will work with Kickstart. If you want to manage the files at runtime and then have them picked up by FusionAuth that is a different problem to solve. For that problem I would recommend you automating a Theme Update API call based upon the changes of your theme files.

robotdan commented 4 years ago

Added some examples https://github.com/FusionAuth/fusionauth-kickstart-examples

soullivaneuh commented 4 years ago

Thanks for the feedback. However, I don't understand why this choice.

A file configuration example with what should be configured (templates, smtp settings etc...) would be a simpler way IMO.

What do you think?

dan-barrett commented 3 years ago

@robotdan Piggybacking on this: is there any way to reference existing UUIDs from the kickstart file?

For example: my first use case is using the kickstart file to configure an application so I don't have to recreate it each time I bounce an environment. But a few important fields in the request body are UUID references to other entities (e.g. jwtConfiguration.accessTokenKeyId). Is there any way for me to reference this UUID in the kickstart file (without hardcoding it of course because the UUID of the key I'm after seems to be generated)?

robotdan commented 3 years ago

@soullivaneuh I think you're just asking for a more complete example that could be used in a general sense as a starting point instead of just the simple example that exists today?

@dan-barrett you can either hard code the Id and then it is known for re-use, or you can generate Ids in the variable section using #{UUID()} and then re-use it that way. Example : https://github.com/FusionAuth/fusionauth-example-kickstart/blob/2d3b5c3aecb1846599d6ec6743ddf20c060119f1/fusionauth/kickstart-kitchen-sink.json#L9

dan-barrett commented 3 years ago

Thanks for the reply @robotdan.

I was hoping to reference the UUID of the Default Signing Key when creating a new Application. That key already exists in the database so I have no control over its creation and thus can't just choose its UUID. It's as if I need to make a GET call first.

Is this scenario supported by Kickstart? Or should I just be creating a new key to use and ignoring the Default Signing Key so I have control over the UUID?

robotdan commented 3 years ago

@dan-barrett Ah.. ok, got it.

Yes, in this case you'll need to just create a new key so you can control the Id.

This looks to be an oversight on our end, we should be providing a way to resolve this Id. We have similar capability for the default forms and lambdas we ship. Please open a separate issue asking for the Id of the default signing key, and we'll get this fixed and documented.